Haben Sie jemals Ihren Rechner hochgefahren und wurden von der kryptischen Fehlermeldung „System wurde nicht mit Systemd als Init-System gebootet” begrüßt? Keine Panik! Dieser Fehler kann frustrierend sein, ist aber in den meisten Fällen behebbar. In diesem Artikel werden wir Ihnen drei effektive Korrekturen zeigen, um dieses Problem zu beheben und Ihr System wieder zum Laufen zu bringen. Wir erklären die Ursachen des Fehlers und führen Sie Schritt für Schritt durch die einzelnen Lösungen.
Was bedeutet die Fehlermeldung „System wurde nicht mit Systemd als Init-System gebootet”?
Bevor wir uns den Lösungen zuwenden, ist es wichtig zu verstehen, was diese Fehlermeldung eigentlich bedeutet. Systemd ist ein Init-System, das in vielen modernen Linux-Distributionen verwendet wird. Es ist im Wesentlichen der erste Prozess, der beim Starten des Systems gestartet wird und für das Starten und Verwalten aller anderen Prozesse verantwortlich ist. Wenn Ihr System *nicht* mit Systemd als Init-System gebootet wird, bedeutet das, dass ein anderes Init-System verwendet wird (vielleicht ein älteres wie SysVinit) oder dass ein Problem im Bootprozess vorliegt, das Systemd am Starten hindert.
Dieser Fehler tritt häufig in Umgebungen auf, in denen Virtualisierungstechnologien wie Docker oder WSL (Windows Subsystem for Linux) verwendet werden. Es kann aber auch auf physischen Maschinen auftreten, insbesondere nach Updates oder Änderungen an der Bootkonfiguration.
Ursachen des Problems
Es gibt verschiedene Gründe, warum diese Fehlermeldung auftritt. Hier sind einige der häufigsten Ursachen:
- Falsche Boot-Konfiguration: Die Konfiguration Ihres Bootloaders (z.B. GRUB) ist möglicherweise falsch konfiguriert, sodass er nicht Systemd als Init-System startet. Dies kann durch manuelle Bearbeitung der Bootloader-Konfiguration oder durch Fehler bei der Installation eines Updates verursacht werden.
- Virtualisierungsprobleme: In virtualisierten Umgebungen können spezifische Konfigurationen erforderlich sein, um sicherzustellen, dass Systemd ordnungsgemäß gestartet wird. Fehlende oder falsche Einstellungen in der VM-Konfiguration können zu diesem Fehler führen.
- Beschädigte Systemdateien: Beschädigte oder fehlende Systemd-Dateien können verhindern, dass das System korrekt bootet. Dies kann durch Festplattenfehler, unsachgemäße Shutdowns oder Fehler bei Softwareinstallationen verursacht werden.
- Kernel-Probleme: In seltenen Fällen kann ein Problem mit dem Kernel selbst dazu führen, dass Systemd nicht gestartet werden kann.
Korrektur 1: Den Bootloader überprüfen und konfigurieren (GRUB)
Die häufigste Ursache für diesen Fehler ist eine fehlerhafte Bootloader-Konfiguration. Wenn Sie GRUB verwenden (was in den meisten Linux-Distributionen der Fall ist), können Sie die Konfiguration wie folgt überprüfen und korrigieren:
- Starten Sie im Rettungsmodus oder verwenden Sie eine Live-Distribution: Um die Bootloader-Konfiguration zu ändern, müssen Sie Zugriff auf das System haben, ohne es normal zu booten. Starten Sie den Computer von einem Live-USB-Stick oder im Rettungsmodus (Recovery Mode). Der Rettungsmodus ist oft über das GRUB-Menü zugänglich.
- Mounten Sie die Root-Partition: Identifizieren Sie die Root-Partition (die Partition, auf der Ihr Betriebssystem installiert ist) und mounten Sie sie. Sie können den Befehl
lsblkverwenden, um die Partitionen aufzulisten. Angenommen, Ihre Root-Partition ist/dev/sda1, verwenden Sie den folgenden Befehl:mount /dev/sda1 /mntWenn Sie eine separate Boot-Partition haben, müssen Sie diese ebenfalls mounten:
mount /dev/sda2 /mnt/boot(Ersetzen Sie
/dev/sda2durch Ihre tatsächliche Boot-Partition) - Chroot in die Umgebung: Verwenden Sie
chroot, um Ihre Umgebung in die Root-Partition zu ändern:chroot /mntDies ermöglicht es Ihnen, Befehle auszuführen, als ob Sie das System normal gebootet hätten.
- Überprüfen Sie die GRUB-Konfiguration: Öffnen Sie die GRUB-Konfigurationsdatei mit einem Texteditor (z.B.
nanoodervim):nano /boot/grub/grub.cfgSuchen Sie nach der Zeile, die den Kernel startet (normalerweise beginnt sie mit
linuxoderlinux16). Stellen Sie sicher, dass die Optioninit=/lib/systemd/systemdvorhanden ist. Wenn sie fehlt, fügen Sie sie hinzu.Beispiel:
linux /boot/vmlinuz-5.15.0-76-generic root=UUID=... ro quiet splash init=/lib/systemd/systemd - Generieren Sie die GRUB-Konfiguration neu: Nach der Änderung der Konfiguration müssen Sie sie neu generieren, damit die Änderungen wirksam werden. Verwenden Sie den Befehl:
update-grubOder, wenn das nicht funktioniert:
grub-mkconfig -o /boot/grub/grub.cfg - Beenden Sie die Chroot-Umgebung und starten Sie neu: Beenden Sie die Chroot-Umgebung mit dem Befehl
exit. Unmounten Sie dann die Partitionen und starten Sie den Computer neu:umount /mnt/boot(falls die boot-Partition separat gemountet wurde)
umount /mntreboot
Korrektur 2: Systemd in Docker/WSL aktivieren
Wenn Sie den Fehler in einer Docker– oder WSL-Umgebung sehen, liegt es wahrscheinlich daran, dass Systemd nicht korrekt aktiviert ist. In diesen Umgebungen wird Systemd oft standardmäßig deaktiviert, um Ressourcen zu sparen. Hier sind die Schritte, um es zu aktivieren:
Für Docker:
- Dockerfile anpassen: Fügen Sie die folgenden Zeilen zu Ihrem Dockerfile hinzu:
ENV container docker CMD ["/sbin/init"]Diese Zeilen setzen eine Umgebungsvariable, die signalisiert, dass der Container in einer Docker-Umgebung läuft, und starten den
/sbin/init-Prozess, der Systemd starten sollte. - Docker-Container neu erstellen: Bauen Sie Ihr Docker-Image neu und starten Sie den Container neu, um die Änderungen zu übernehmen.
Für WSL:
- `wsl.conf` bearbeiten: Öffnen Sie die Konfigurationsdatei `wsl.conf` mit einem Texteditor. Diese Datei befindet sich normalerweise unter `/etc/wsl.conf`. Falls die Datei nicht existiert, erstellen Sie sie.
sudo nano /etc/wsl.conf - Systemd aktivieren: Fügen Sie die folgenden Zeilen zur `wsl.conf`-Datei hinzu:
[boot] systemd=true - WSL neu starten: Schließen Sie alle WSL-Fenster und führen Sie den folgenden Befehl in der Windows-Eingabeaufforderung oder PowerShell aus, um WSL neu zu starten:
wsl --shutdownWarten Sie, bis WSL vollständig beendet wurde (dies kann einige Sekunden dauern) und starten Sie dann Ihre WSL-Distribution erneut.
Korrektur 3: Systemdateien überprüfen und reparieren (als fortgeschrittene Option)
Wenn die oben genannten Lösungen nicht funktionieren, könnte das Problem durch beschädigte Systemd-Dateien verursacht werden. Diese Korrektur ist fortgeschritten und sollte nur durchgeführt werden, wenn Sie mit der Linux-Befehlszeile vertraut sind. Sie müssen von einem Live-Medium booten, um diese Schritte auszuführen.
- Booten Sie von einem Live-Medium: Starten Sie Ihren Computer von einem Live-USB-Stick oder einer Live-CD.
- Mounten Sie die Root-Partition (wie in Korrektur 1 beschrieben): Identifizieren Sie die Root-Partition und mounten Sie sie.
- Überprüfen Sie die Integrität der Systemdateien: Verwenden Sie ein Tool wie `debsums` (für Debian-basierte Systeme) oder ein ähnliches Tool für Ihre Distribution, um die Integrität der Systemd-Dateien zu überprüfen. Installieren Sie `debsums` (falls nicht bereits installiert) und führen Sie es aus:
apt update apt install debsums debsums -c systemdDieser Befehl vergleicht die Prüfsummen der installierten Systemd-Dateien mit den erwarteten Prüfsummen. Wenn beschädigte Dateien gefunden werden, werden diese aufgelistet.
- Ersetzen Sie die beschädigten Dateien: Wenn beschädigte Dateien gefunden wurden, müssen Sie diese ersetzen. Die einfachste Methode ist, die Systemd-Pakete neu zu installieren. Chrooten Sie zuerst in die Root-Partition (wie in Korrektur 1 beschrieben) und führen Sie dann den folgenden Befehl aus:
apt update apt --reinstall install systemdDies lädt die Systemd-Pakete neu herunter und installiert sie neu, wodurch beschädigte Dateien ersetzt werden.
- Beenden Sie die Chroot-Umgebung und starten Sie neu: Beenden Sie die Chroot-Umgebung, unmounten Sie die Partitionen und starten Sie den Computer neu.
Fazit
Die Fehlermeldung „System wurde nicht mit Systemd als Init-System gebootet” kann beunruhigend sein, ist aber in den meisten Fällen behebbar. Beginnen Sie mit der Überprüfung Ihrer Bootloader-Konfiguration (Korrektur 1). Wenn Sie in einer virtualisierten Umgebung arbeiten, stellen Sie sicher, dass Systemd korrekt aktiviert ist (Korrektur 2). Als letzte Option können Sie die Integrität Ihrer Systemdateien überprüfen und beschädigte Dateien ersetzen (Korrektur 3). Mit diesen Korrekturen sollten Sie Ihr System wieder zum Laufen bringen können. Denken Sie daran, dass die Befehlszeilenarbeit unter Linux etwas Übung erfordert. Seien Sie vorsichtig und lesen Sie die Anweisungen sorgfältig durch. Viel Erfolg!