Linux setzt sich aus quelloffenen, gut dokumentierten Komponenten zusammen. OpenSuse-Anwender sollten das nutzen, um ihr System zu verstehen und zu reparieren, statt es wie Windows bei Problemen einfach neu zu installieren.

Als erste Komponente eines Linux-Systems tritt der Bootloader Grub [1] in Aktion (Abbildung 1). Seine Aufgabe ist es, den Linux-Kernel zu laden und ihm ein Mini-Dateisystem mit grundlegenden Treibern für die Festplattenhardware, das Dateisystem und die Tastatur bereitzustellen.

Abbildung 1: Bei OpenSuse bietet das Grub-Startmenü die Option, einen automatisch bei jeder Softwareinstallation und Konfigurationsänderung mit YaST angelegten Snapshot zu starten.

Die Hardware kann nach dem Einschalten den Bootloader auf zwei verschiedene Arten aufrufen: über den seit Erscheinen der PC-Architektur in den 80er-Jahren üblichen Boot-Sektor oder mithilfe der neueren UEFI-Systempartition [2]. Bei Letzterer handelt es sich um eine kleine Partition mit FAT32-Dateisystem, in die Linux oder Windows eine standardisierte Bootloader-Programmdatei ablegen (Abbildung 2). Die Koexistenz von Bootloadern mehrerer Systeme ist erlaubt.

Abbildung 2: Eine FAT32-Partition anstelle des alten, nur 1 KByte großen Bootsektors erlaubt die parallele Installation mehrerer Bootloader.

In einem laufenden Linux-System prüfen Sie anhand der Datei /sys/firmware/efi, ob der Start via UEFI erfolgte oder über eine Emulation des früheren BIOS, von Motherboard-Herstellen oft CSM (Compatibility Support Module) genannt (Abbildung 3). Gibt es diese Datei, läuft ein UEFI-System, ansonsten ist Linux im BIOS(-Kompatibilitäts)-Modus gestartet.

Abbildung 3: Viele Motherboards unterstützen noch einen BIOS-Kompatibilitätsmodus, bei dem Grub von einem althergebrachten Boot-Sektor aus startet.

Fährt das System klaglos hoch, müssen Sie sich nicht weiter um den vom OpenSuse-Installer eingerichteten Bootloader kümmern. Aufmerksamkeit erfordert er erst, wenn nach dem Einschalten des Rechners das Grub-Startmenü nicht mehr erscheint (Abbildung 4). Bei BIOS-Systemen sehen Sie dann nur noch einen blinkenden Cursor; ein UEFI-System bietet an, nach einem startbaren Betriebssystem zu suchen. Startet die erste Phase des Bootloaders noch, erscheint die Grub-Rettungs-Shell (Abbildung 5), falls der Bootloader keinen zu startenden Linux-Kernel findet.

Abbildung 4: Findet UEFI kein startbares System, erscheint in der Regel ein Auswahlbildschirm. Der hilft aber nicht weiter, wenn das Bootloader-Binary verschwunden ist.

Abbildung 5: Wer sich mit der dahinterstehenden Technik auseinandersetzen möchte, kann mit der Grub-Rettungs-Shell den Kernel und die initiale RAM-Disk per Hand auswählen.

Nützlicher Werkzeugkasten

Tatsächlich macht es OpenSuse leicht, einen streikenden Bootloader zu reparieren: Es genügt, das System von einer Installations-DVD zu booten und dabei im Startmenü den Eintrag More/Boot Linux System auszuwählen. Das DVD-System findet installierte OpenSuse-Installationen und startet sie per externem Bootloader. Läuft das nicht mehr eigenständig startbare System dann, genügt es, dort das YaST-Modul Bootloader zu öffnen (Abbildung 6) und auf OK zu klicken, um Grub erneut zu installieren.

Abbildung 6: Das YaST-Modul Bootloader installiert Grub vollautomatisch neu, egal, ob auf UEFI- oder BIOS(-Kompatibilitäts-)-Systemen.

Ob es sich um ein UEFI- oder BIOS-System handelt, erkennt YaST selbstständig. Unter Bootloader-Optionen wählen Sie das Timeout des Grub-Menüs oder das standardmäßig startende System aus. Zudem dürfen Sie in YaST die Optik des Grub-Startmenüs verändern (Abbildung 7). Laden Sie dafür zum Beispiel ein Theme für Grub2 herunter [3] und entpacken Sie die Dateien als Root unter /boot/grub2/themes/ in einen eigenen Unterordner. Wählen Sie dort die Datei theme.txt aus, damit Grub beim nächsten Systemstart in einer neuen Optik erscheint. Die Suse-Dokumentation erläutert Grub im Detail [4].

Abbildung 7: Dank Grub-Themes wie dem aus https://www.gnome-look.org/p/2142488 muss das Boot-Menü nicht in Suse-Grün verbleiben.

Auch ohne Installations-DVD funktioniert ein alter Trick zum Fixen des Bootloaders: eine sogenannte Chroot-Umgebung (Abbildung 8). Dabei hängen Sie aus einem Life-System heraus das zu reparierende Root-Dateisystem in ein Unterverzeichnis ein und erklären es für eine Shell-Umgebung zur Systemwurzel (Root). Jetzt können Sie alle im fraglichen System installierten Kommandozeilenprogramme aufrufen. Darum kommt eine Chroot-Umgebung nicht nur bei einem fehlerhaften Bootloader zum Einsatz, sondern auch bei vielen weiteren Reparaturaufgaben.

Abbildung 8: Ein Chroot führt den Kernel eines laufenden Live-Systems und das Root-Dateisystem eines nicht mehr startenden Systems für Wartungsaufgaben zusammen.

Zum Einrichten eines Chroots starten Sie das Rettungssystem von der OpenSuse-Installations-DVD oder booten, falls eine grafische Umgebung gewünscht ist, eine Live-DVD [5]. Hängen Sie das Root-Dateisystem des fehlerhaften Systems unter /mnt ein, zum Beispiel mit dem Kommando sudo mount /dev/sda2 /mnt, wenn es sich bei der zweiten Partition der ersten Festplatte um Ihre Root-Partition handelt. Sie können Gparted (Abbildung 9) zu Hilfe nehmen, um die Root-Partition zu finden. Ist die Root-Partition unter /mnt verfügbar, dann spiegeln Sie einige wichtige Systemverzeichnisse (Listing 1).

Abbildung 9: Der grafische Festplattenpartitionierer Gparted lässt sich auf einem OpenSuse-Live-System schnell nachinstallieren.

# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --rbind /sys /mnt/sys

Hereinspaziert

Betreten Sie dann das Chroot mit dem Kommando chroot /mnt. Unter OpenSuse müssen Sie als Btrfs-Subvolumes angelegte Unterverzeichnisse wie /var mit mount -a (mounten aller in /etc/fstab registrierten Dateisysteme) einhängen.

Sie können in der Chroot-Umgebung den Bootloader mit grub-install /dev/sda erneut auf der ersten Festplatte des Rechners installieren. Für die erste direkt im M.2-Slot [6] auf dem Motherboard installierte SSD lautet der Aufruf grub-install /dev/nvme0. Die zweite Festplatte sprechen Sie als sdb an, die zweite SSD als nvme1 und so weiter.

Hängt ein Systemstart mit der Meldung Loading initial ramdisk… file […] not found, dann ist in aller Regel das letzte Update nicht bis zum Ende durchgelaufen. Daher fehlt die zum Schluss erzeugte, zum Einhängen des Root-Dateisystems erforderliche initiale RAM-Disk. Dann hilft der Aufruf dracut --regenerate-all weiter, der die RAM-Disks für alle installierten Kernel neu erzeugt. Informationen zu Dracut finden Sie im Github-Repository der Software [7].

Aus einem Chroot heraus lässt sich auch ein Tumbleweed-System nach einem vorzeitig abgebrochenen Paket-Upgrade-Vorgang in einen konsistenten Zustand zurückversetzen – zumindest, wenn das Paketverwaltungsprogramm Zypper noch funktioniert.

Möchten Sie aus dem Chroot heraus Pakete installieren, aktiviert der Aufruf aus Listing 2 den sonst eher unbeliebten, doch leicht greifbaren Nameserver von Google, der Domainnamen wie opensuse.org auflöst. Nun funktioniert Zypper in der Chroot-Umgebung wie gewohnt. Haben Sie versehentlich ein wichtiges Systempaket entfernt, lässt es sich neu installieren. Ein zypper dup setzt ein vorzeitig abgebrochenes Upgrade fort.

# echo 'nameserver 8.8.4.4' | sudo tee -a /etc/resolv.conf

Zypper weist nur wenige Abhängigkeiten auf. Dennoch kann ein Abbruch eines Upgrades dazu führen, dass das Programm und seine Hilfsbibliotheken inkonsistent zurückbleiben (Abbildung 10). Der GAU beim Upgrade besteht darin, dass die von allen Programmen genutzte Basisbibliothek Glibc in einer nicht zum restlichen System passenden Version auf der Festplatte landet. Dann funktionieren nicht einmal mehr Tools wie Ls oder Cd.

Abbildung 10: Es passiert selten, kommt aber vor, dass nach einem abgebrochenen Upgrade wie hier die Paketverwaltung nicht mehr funktioniert.

Ein Weg zurück

Tatsächlich muss nicht einmal eine solche kapitale Havarie OpenSuse-Anwendern den Schweiß auf die Stirn treiben: Zur Abhilfe genügt es, im Boot-Menü unter Start Bootloader from read-only snapshot in einen intakten Schnappschuss zu booten und ihn mit sudo snapper rollback zu reaktivieren. Mit sudo snapper list -t pre-post listen Sie die vorliegenden System-Snapshots auf (Abbildung 11). Bei Bedarf kehrt snapper rollback Nummer zu einem noch weiter zurückliegenden Snapshot aus dieser Aufstellung zurück.

Abbildung 11: OpenSuse legt bei jeder Softwareinstallation oder Konfigurationsänderung automatisch mit YaST einen Systemschnappschuss an.

OpenSuse installiert das auf Snapper [8] basierende Rollback-System seit OpenSuse 42.1 von Ende 2015. Nutzer waren aber auch vorher schon bei einem vorzeitig abgebrochenen Update-Vorgang keineswegs hilflos: Mithilfe eines Live-Systems und eines extern ausgeführten Paketmanagers gelang eine Rettung selbst bei einer inkompatiblen Libc-Version und disfunktionalen Core-Utilities.

Zypper kennt noch immer die dafür nötige Option --root, die das Tool anweist, ein Unterverzeichnis als Root für die Paketinstallation zu betrachten. Es erweist sich manchmal als praktischer, den zerschossenen Systemschnappschuss zu reparieren, statt zum vorausgehenden zurückzuwechseln und damit alle seitdem vorgenommenen systemweiten Konfigurationsänderungen zurückzunehmen.

Mounten Sie für eine solche Rettung eines Tumbleweed-Systems das Root-Dateisystem des beschädigten Systems und spiegeln Sie wie als Vorbereitung zum Chroot beschrieben /proc, /sys und /dev. Diesmal führen Sie aber nicht chroot aus, sondern führen aus dem Live-System heraus das Kommando sudo zypper --root /mnt dup aus. Es spielt den aktuellen, in sich konsistenten Satz an Paketen ein. Unter Leap führen unterbrochene Updates übrigens meist nicht zu einem nicht mehr startfähigen System.

OpenSuse setzt standardmäßig auf den Dateisystemtyp Btrfs. Das leistungsfähige Dateisystem bietet fortschrittliche Optionen, zeigt sich jedoch anfälliger für Datenkorruption als ein Ext4-Dateisystem. Zur Datenverfälschung kommt es aber in beiden Fällen. Btrfs kennt die Mount-Option recovery, die in manchen Fällen die interne Struktur des Dateisystems reparieren kann. Manche Anwender fügen diese Option permanent in die Datei /etc/fstab ein, damit Linux fehlerhafte Dateisysteme stillschweigend repariert und das System normal startet.

In vielen Fällen deutet ein korruptes Dateisystem allerdings auf eine Instabilität im Rechner hin. Daher empfiehlt es sich, erst nach Meldungen wie in Listing 3 das Root-Dateisystem aus einem Rettungssystem heraus mit der Recovery-Option einzuhängen. Die im entsprechenden Befehl aus der letzten Zeile des Listings angegebene Gerätedatei sda2 entspricht dem Standard bei der Installation auf der ersten Festplatte eines UEFI-Systems. Für Ihren Rechner müssen Sie die Angabe gegebenenfalls anpassen. Ist das Dateisystem dann lesbar, versuchen Sie einen Systemneustart. Eine weitere Mount-Option, die Sie probieren können, lautet -o clear_cache.

[...]
Btrfs: Transaction aborted (error -2)
[...]
[<ffffffffa041277b>] __btrfs_abort_transaction+0x4b/0x120 [btrfs]
[<ffffffffa0445f87>] __btrfs_unlink_inode+0x367/0x3c0 [btrfs]
[<ffffffffa04499e7>] btrfs_unlink_inode+0x17/0x40 [btrfs]
[<ffffffffa0449a76>] btrfs_unlink+0x66/0xb0 [btrfs]
kernel: Btrfs warning (device sdb3): __btrfs_unlink_inode:3802: Aborting unused transaction(No such entry).
# mount -t btrfs -o recovery,ro /dev/sda2 /mnt

Reise zum Kern

Hat der Bootloader den Linux-Kernel geladen und das Root-Dateisystem (vorläufig nur lesbar) eingehängt, startet endlich das Linux-System. Dazu ruft der Kernel Systemd [9] auf, das daraufhin direkt oder indirekt jeden laufenden Prozess startet. Der Aufruf systemctl status zeigt die Prozessbaumstruktur (Abbildung 12), eingeteilt in user.slice (an ein Benutzerkonto gebundene Prozesse) und system.slice (systemweite Dienste mit Root-Rechten).

Abbildung 12: Der Befehl systemctl status gibt eine lange Liste aller laufenden System- und Anwenderdienste zurück.

Ein besonders wichtiger Systemdienst ist der Udev-Daemon: Er erhält vom Kernel eine Meldung, falls dieser ein neues Gerät erkennt. Udev startet dann beliebige Programme oder Bash-Skripte. Typische Aufgaben für Udev bestehen im automatischen Mounten eines USB-Sticks oder dem Start der Wiedergabe einer Audio-CD. Gegebenenfalls setzen Udev-Regeln [10] selbst exotische Ideen um, wie das Hochfahren einer grafischen Umgebung auf einem Server erst nach dem Anschließen eines Monitors.

Allerdings erfordert Udev einiges Know-how und weist eine steile Lernkurve auf. Die bei OpenSuse mitgelieferten Udev-Regeln finden sich unter /usr/lib/udev/rules.d/, eigene gehören ins Verzeichnis /etc/udev/rules.d/. Kopieren Sie mitgelieferte Regeln, die Sie verändern möchten, dorthin, damit ein Systemupdate sie nicht überschreibt.

Eine weitere Schnittstelle zum Kernel liegt in Form des Verzeichnisses /etc/modprobe.d/ vor. Hier geben Sie Parameter für Kernel-Module vor und passen damit das Verhalten des Kernels an. Auskunft über geladene Kernel-Module gibt der Befehl lsmod (Abbildung 13). Die Eingabe von modinfo Modul nennt Parameter, die Sie in .conf-Dateien unter /etc/modprobe.d/ ablegen können.

Abbildung 13: Lsmod zeigt alle geladenen Kernel-Module (“Treiber”) an.

Die von der Distribution mitgelieferten Konfigurationsdateien liegen unter /lib/modprobe.d/. Möchten Sie eine dieser Dateien verändern, empfiehlt es sich, sie nach /etc/modprobe.d/ zu kopieren, damit Aktualisierungen Ihre Anpassungen nicht überschreiben. Bei Bedarf legen Sie dort eine neue Datei an.

Ein Beispiel für eine bei OpenSuse mitgelieferte Kernel-Treiberkonfiguration ist die Auto-Close-Funktion von optischen Laufwerken. In /lib/modprobe.d/ findet sich die Datei 80-options-cdrom.conf mit der (von Kommentaren abgesehen) einzigen Zeile options cdrom autoclose=0. Die Eingabe options cdrom legt fest, dass in der Zeile nun die Optionen für das Kernel-Modul cdrom folgen. Der Aufruf von modinfo cdrom (Abbildung 14) nennt als mögliche Parameter (parm) unter anderem autoclose:bool, autoeject:bool und lockdoor:bool.

Abbildung 14: Modinfo nennt die Parameter, über die sich ein Kernel-Modul im Verzeichnis /etc/modprobe.d/ konfigurieren lässt.

Der Datentyp bool nach dem Doppelpunkt steht für “ja/nein”, das Sie in den Konfigurationsdateien als 1 respektive 0 angeben. In unserem Fall schaltet options cdrom autoclose=0 das automatische Schließen des CD-ROM-Laufwerks aus (Option autoclose für das Kernel-Modul cdrom ist 0). Möchten Sie diese Einstellung ändern, kopieren Sie die Datei 80-options-cdrom.conf nach /etc/modprobe.d/ und verändern den autoclose-Parameter zu autoclose=1. Bei Bedarf fügen Sie der Zeile options cdrom durch Leerzeichen getrennt weitere Optionen hinzu, zum Beispiel options cdrom autoclose=1 autoeject=1.

Weitere mögliche Werte für Datentypen der Modulparameter sind int (Ganzzahl) oder charp (Zeichenkette). Eine umfassende, über die Ausgaben von Modinfo hinausgehende Dokumentation für alle Kernel-Modul-Parameter gibt es nicht. Im Zweifelsfalls hilft nur eine Suche im Internet weiter.

Immerhin wissen Sie jetzt, wie Sie Parameter in .conf-Dateien angeben, sollten Sie im Internet Hinweise auf eine mögliche Problemlösung finden. Oft wird hier empfohlen, den Modulparameter per Kernel-Kommandozeile zu setzen, sprich durch einen Eintrag in die Datei /etc/default/grub. Bei diesem Vorgehen vergisst man aber leicht, anschließend noch grub-mkconfig auszuführen, um die Änderungen in /etc/default/grub auch in die aktive Bootloader-Konfiguration zu übertragen.

Die einzelne dafür vorgesehene Zeile gerät zudem schnell unübersichtlich, während Sie unter /etc/modprobe.d/ die Anpassungen auf beliebig viele Dateien verteilen. Daher empfiehlt es sich, bei letztgenannter Konfigurationsmöglichkeit für Kernel-Module zu bleiben. Einen für die Grub-Konfiguration vorgesehenen Eintrag wie nvidia_drm.modeset=1 verwandeln Sie einfach in options nvidia_drm modeset=1 und platzieren ihn in eine beliebig benannte Datei mit der Endung .conf in /etc/modprobe.d/.

Ein Reboot stellt die praktikabelste Möglichkeit dar, die Änderung zu aktivieren: Das Entladen eines Moduls mit modprobe -r und ein Neuladen mit modprobe funktioniert zwar prinzipiell, scheitert in der Praxis aber oft an Modulabhängigkeiten oder daran, dass sich aktiv genutzte Module nicht entladen lassen.

Nicht dienstbar

Nach einem abgeschlossenen Systemstart prüfen Sie per systemctl --failed (als Root) beziehungsweise systemctl --user --failed (als normaler Benutzer), ob alle Dienste erfolgreich gestartet sind. Passt alles, dann bleiben die resultierenden Listen leer. Ansonsten führt Systemctl die Dienste auf, deren Start gescheitert ist.

Die Tabelle “Zentrale Systemdienste” nennt einige wichtige Dienste und deren Funktion. Drücken Sie in der Boot-Animation, die direkt nach dem Bootloader-Menü erscheint, die Escape-Taste, dann sehen Sie die (Miss-)Erfolgsmeldungen für den Start der Dienste auch ohne gesonderten Kommandozeilenaufruf.

Listet systemctl --failed fehlgeschlagene Dienste auf, dann sehen Sie sich mit journalctl -u Dienst die zugehörigen Fehlermeldungen an. Bei Systemdiensten nehmen Sie den Aufruf als Root vor, bei Benutzerdiensten fügen Sie stattdessen den Parameter --user hinzu. Die Übersichtlichkeit verbessert ein am Ende angehängtes -xeb: Es blendet die vollen Meldungen (-x) in umgekehrter Reihenfolge (-e) ein und beschränkt das Log auf den Zeitpunkt seit dem Systemstart (-b).

Ist das System bis auf einen fehlgeschlagenen Dienst lauffähig, recherchieren Sie die Fehlerursachen in der gewohnten Arbeitsumgebung. Startet die grafische Oberfläche nicht, aber Sie sehen einen Login-Prompt, dann melden Sie sich an. Unter KDE Plasma rufen Sie dann mit startplasma-wayland Ihre gewohnte Arbeitsumgebung auf, selbst wenn der X-Server nicht mehr funktioniert. Für Gnome funktioniert das mit dem Kommando aus Listing 4.

# XDG_SESSION_TYPE=wayland dbus-run-session gnome-session

Aus einer solchen Gnome-Session befreien Sie sich wie generell aus einer nicht mehr reagierenden grafischen Umgebung: [Strg]+[Alt]+[F3] bringt Sie auf eine reine Textkonsole außerhalb der grafischen Umgebung. Funktioniert das nicht, dann drücken Sie zuvor [Alt]+[Druck]+[R]. Das verlagert die Tastatureingaben von der grafischen Umgebung zurück auf die Kernel-Ebene. Der Linux-Systemkern friert sehr selten ein.

Auf der tty genannten reinen Textkonsole loggen Sie sich wie gewohnt ein. Sie dürfen dort alle Konsolenbefehle genauso ausführen wie in einem Konsolenfenster innerhalb der grafischen Umgebung. Tatsächlich heißen die grafischen Konsolenprogramme Terminalemulator und emulieren eben die Textkonsole, auf der Sie sich nun befinden. [Strg]+[Alt]+[F2] oder [Strg]+[Alt]+[F1] bringt Sie zurück zur grafischen Umgebung, je nachdem, ob eine Wayland- oder eine X11-Sitzung läuft.

Die Eingabe von [Strg]+[Alt]+[Entf] löst auf einer Textkonsole einen Reboot mit einem sauberen Aushängen der Dateisysteme aus. Lediglich ungespeicherte Dokumente in den Anwendungen gehen verloren. Auch ein Login per SSH und die Eingabe von reboot funktionieren selbst bei einer eingefrorenen grafischen Umgebung oft noch.

Sollte der Reboot so nicht klappen, ist es immer noch zu früh für ein Aus- und Wiedereinschalten der Hardware. Versuchen Sie zuerst noch die Tastenabfolge [Alt]+[Druck]+[R][Alt]+[Druck]+[E][Alt]+[Druck]+[I][Alt]+[Druck]+[S][Alt]+[Druck]+[U][Alt]+[Druck]+[B]. Eine Merkhilfe dazu bietet der sinnige Satz “Reboot Even If System Utterly Broken”. Die richtige Tastenfolge ergibt sich aus den Anfangsbuchstaben der Wörter mit vorangestelltem [Alt]+[Druck].

Diese Sequenz beendet auf Kernel-Ebene alle noch reagierenden Prozesse, schreibt alle zwischengespeicherten Daten auf die Festplatten oder SSDs und startet den Rechner neu. Die Gefahr, das System zu beschädigen, ist dabei deutlich geringer als beim schlichten Abschalten der Netzspannung.

Schiefgegangen!

Macht ein Reboot alles wieder gut? Für Linux gilt das oft nicht. Wenn etwas nicht funktioniert, liegt meist eine Fehlkonfiguration vor, die ein Neustart nicht behebt. Bleibt das System nach der Bootloader-Phase hängen, bietet Systemd selbst einen Rettungsmodus an, in dem außer einer minimalen Kommandozeilenumgebung keine Dienste laufen. Darin editieren Sie mit Konsoleneditoren wie Vim [11] oder Nano [12] Konfigurationsdateien, installieren mit Zypper Pakete oder (de-)aktivieren per Systemctl Dienste.

Um in den Rettungsmodus zu booten, drücken Sie im Grub-Boot-Menü [E]+, um die Parameter zu bearbeiten, mit denen der Bootloader den Kernel startet (Abbildung 15). Bewegen Sie den Cursor in die Zeile mit dem eingerückten Wort linux und drücken Sie [Ende]+. Fügen Sie dann durch ein Leerzeichen abgetrennt systemd.unit=rescue.target an das Ende dieser Zeile an. Dann starten Sie das System mit [F10]+. Im Rettungsmodus greift das englische Tastaturlayout: [Z]+ und [Y]+ sind vertauscht, das Gleichheitszeichen finden Sie rechts neben [ß]. Der Startprozess endet mit einer Aufforderung, das Administratorpasswort einzugeben.

Abbildung 15: Die Eingabe [E] öffnet im Grub-Boot-Menü einen Texteditor, in dem sich die Zeile editieren lässt, die den Linux-Kernel startet.

Systemd und seine Benutzerschnittstelle Systemctl sind bei Systemproblemen nicht gefragt. Während Ubuntu installierte Server-Dienste üblicherweise gleich nach der Installation startet, ist das unter OpenSuse meist nicht der Fall. Installieren Sie also auf Ihrem System etwa den Webserver Apache, dann müssen Sie den entsprechenden Server-Dienst aktivieren. Dazu geben Sie als Root auf der Konsole systemctl enable apache2 --now ein, was das System sofort startet und die Einstellung für künftige Systemstarts konserviert. Das Kommando systemctl disable apache2 --now bewirkt das Gegenteil. Mit systemctl start apache2 und systemctl stop apache2 starten und stoppen Sie den Webserver für die aktuelle Sitzung, systemctl restart apache2 löst einen Neustart des Diensts aus.

Wichtig ist noch der Befehl systemctl status apache2: Er verrät, ob der Dienst im Moment läuft. Das ist der Fall, wenn in der Befehlsrückgabe der grüne Schriftzug active (running) erscheint. In diesem Fall zeigt Systemctl noch eine Tabelle der Prozesse des Diensts und seine letzten Meldungen an. Alle relevanten Ausgaben seit dem Systemstart fördert wie bei fehlgeschlagenen Prozessen das Kommando journalctl -u apache2 -xbe zutage.

Fazit

Die OpenSuse-Installations-DVD bietet eine Funktion, die Systemen mit zerstörtem Bootloader von außen auf die Beine hilft, sodass anschließend YaST die Bootloader-Neuinstallation vollautomatisch erledigen kann.

Dennoch lohnt es sich für OpenSuse-Anwender, zu wissen, wie man aus einem externen Live-System heraus den Bootloader in Handarbeit neu installiert, unterbrochene Aktualisierungen zu Ende führt, Änderungen an Konfigurationsdateien mit fatalen Auswirkungen rückgängig macht oder fehlende Initial RAM-Disks erzeugt.

Erfahrene Anwender kommen auf diese Weise oft schneller wieder zu einem funktionierenden System als durch das unter OpenSuse immer mögliche Zurückspielen eines alten Systemzustands. (uba)