☰

Nach einem langwierigen Boot-Reparaturprozess lande ich in der systemd-Notfall-Eingabeaufforderung. Problem: Fehlendes FS in der fstab-Datei

tag-icon • tag-icon boot systemd fstab grub-efi multi-user
Nach einem langwierigen Boot-Reparaturprozess lande ich in der systemd-Notfall-Eingabeaufforderung. Problem: Fehlendes FS in der fstab-Datei

Mir ist bewusst, dass es bereits mehrere Fragen von Leuten gibt, die bereits Probleme beim Booten hatten, aber ich glaube, meiner ist ein ziemlich spezieller Fall. Daher stelle ich noch eine weitere Frage in der Hoffnung, einige neue Probleme anzusprechen.

Ich habe den Startvorgang einer VM repariert, die einen initramfs( initrd.imgund vmlinuzDateien darin /boot) von nicht mehr installierten Kerneln hatte, und habe versucht, weiterhin von ihnen zu starten.

Ich bin fast fertig, aber es startet immer wieder in systemd's neu emergency mode(wo es heißt:)

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Ich habe von einer Live-CD gebootet, die drei entsprechenden Partitionen auf gemountet /mntund per Chroot auf Folgendes umgeleitet /mnt:

mount /dev/sda3 /mnt
mount /dev/sda2 /mnt/boot
mount /dev/sda1 /mnt/boot/efi
for i in proc dev dev/pts sys tmp run; do mount --bind /$i /mnt/$i; done
chroot /mnt

Habe meine Reparaturen durchgeführt und einen Neustart durchgeführt.

Jetzt fstabmountet mein meine Partitionen nicht. Ich dachte, es wäre richtig konfiguriert – UUIDs werden direkt von kopiert blkid | grep /dev/sda. Ich dachte nicht, dass etwas fehlt.

Hier sind die Fehler, die mir direkt vor der Eingabeaufforderung für den Notfallmodus angezeigt werden:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
[DEPEND] Dependency failed for Local File Systems
[DEPEND] Dependency failed for Unattended Upgrades Shutdown
[DEPEND] Dependency failed for /boot/efi

Also habe ich mir natürlich angesehen systemctl status boot.mount, aber es ist aktiv (grün) und zeigt an, dass es geladen ist, obwohl mein /bootOrdner leer ist, sofern ich es nicht manuell mounte /dev/sda2.

Scheint sehr seltsam. Warum wird boot.mountgesagt, dass die Partition geladen wird /boot, wenn dies eindeutig nicht der Fall ist?

Antwort1

Ich habe das Problem also tatsächlich herausgefunden, während ich die Frage geschrieben habe. Wie Sie aus dem, was ich am Anfang geschrieben habe, ersehen können, war es ein sehr langer Prozess (ich hatte etwa 2 Tage daran gearbeitet, bevor ich an den Punkt kam, an dem ich um Hilfe bitten wollte).

Wenn Sie sich das Ende der Frage ansehen, sehen Sie, dass ich dmesgwährend des Bootvorgangs diese Meldung erhalten habe:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

Also habe ich natürlich versucht, systemctl status boot.mountnachzuschauen, was da steht, aber da stand „ boot.mountist aktiv (grün), es ist geladen und funktioniert ordnungsgemäß“, obwohl /bootes leer war, sofern ich es nicht manuell gemountet habe /dev/sda2(was genau das Gegenteil von dem ist, was ich erwarten würde).

Also begann ich zu denken, dass etwas mit dem Dienst nicht stimmte. Ich habe ihn deaktiviert, boot.mountobwohl ersagtees hat einwandfrei funktioniert:

systemctl disable --now boot.mount

Ich habe versucht, es wieder zu aktivieren, aber es ist eine Fehlermeldung aufgetreten:

systemctl enable --now boot.mount
Failed to enable unit: Unit /run/systemd/generator/boot.mount is transient or generated

OK, das macht Sinn, es wird durch den Bootvorgang ausgelöst und kann nicht durch einen Benutzerbefehl aufgerufen werden. Also habe ich versucht, alle Geräte erneut zu mounten mit:

mount -a

Und sah, dass die Datei einen Fehler enthielt /etc/fstab:

error: rw,relatime is not a valid file system

(oder so ähnlich).

Der Schlüssel hier ist, wenn ich nicht versucht hätte, das Dateisystem manuell zu mounten, hätte ich dieses Feedback nie erhalten. Die Fehlermeldung, die mount -aman erhält, wenn fstabsie eine falsche Syntax enthält, ist unglaublich hilfreich. Viel hilfreicher als:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

... und dann wird eine „funktionierende“ systemd-Einheit angezeigt, boot.mountwenn /bootsie nicht gemountet wird (obwohl sietatbring mich schließlich an den richtigen Ort).

Also habe ich die bearbeitet fstabund die Dateisysteminformationen für die /bootPartition eingegeben, die nicht gemountet werden konnte. Dann habe ich sie erneut ausgeführt mount -a(was im Wesentlichen dasselbe bewirkt wie boot.mount) und eine positive Antwort erhalten.

Jetzt werden die beiden Partitionen nach einem Neustart ordnungsgemäß gemountet und alles ist gut im Land von Meerrettich und Marmelade.

Wenn hierdurch keines Ihrer Probleme behoben wird, finden Sie hier einige zusätzliche Hinweise zu dem Prozess, den ich durchlaufen habe, bevor ich zu dem oben genannten Punkt gelangte, an dem ich nach Hilfe suchte (Sie können ruhig mit dem Lesen aufhören, wenn Sie bei Ihrem Problem angekommen sind):

Das ursprüngliche Problem, das ich vor zwei Tagen hatte, war, dass das System versuchte, von Kerneln zu booten, die nicht mehr auf dem System vorhanden waren. Nachdem ich mit der Live-CD gebootet hatte, löschte ich den Inhalt des Ordners (in dem sich /bootalle Dateien befinden).initrd

initramfsIch dachte, ich würde einfach die using -Dateien aus den aktuell installierten Kerneln neu erstellen , aber dann stellte ich fest, dass ich die oder -Dateien update-initramfs -c -k allnicht allein mit neu erstellen konnte . Dies erwies sich als etwas problematischer, als ich erwartet hatte.configSystem.mapdepmod

Der einfachste Weg, alle diese Dateien neu zu generieren oder abzurufen, ist meiner Meinung nach:

  1. lösche den gesamten Inhalt von /boot,
  2. Deinstallieren Sie alle Dateien linux-image, linux-headerdie linux-modulesich nicht verwenden wollte.
  3. Löschen Sie alle restlichen Verzeichnisse in /usr/lib/modulesund dann
  4. Neuinstallation und Dateien linux-image, die ich verwenden wollte (die aktuellsten zwei generischen Versionen)linux-moduleslinux-headers

Hinweis: Die Neuinstallation dieser 3 Dateitypenalles zur selben ZeitSo habe ich es geschafft, die Dateien /boot/System.mapund wiederherzustellen - vorher hat es nicht geholfen, /boot/configdie Dateien einfach neu zu installieren . Es ist möglich, dass sie in (Module wären sinnvoll) oder Paketen enthalten sind, aber so hat es bei mir funktioniert.linux-imagemodulesheaders

  1. Anschließend habe ich update-grubdie Dateien neu installiert und bestätigt, dass /bootsie richtig ausgefüllt wurden.
  2. Ich habe auch bootctl installund ausgeführt /etc/kernel/postinst.d/zz-udpate-systemd-boot, daher hätte ich systemd-bootes als Fallback installiert.

An einem Punkt nach einem Neustart musste ich die Konfiguration system.targetauf multi-user.targetanstelle von ändern graphical.target, wahrscheinlich, weil ich vor ein paar Tagen chrootalle diese Mounts auf einer grafischen Live-CD verwendet hatte, um das boot-repairProgramm auszuführen, wofür Grafiken erforderlich sind (und die, glaube ich, /dev/pts /tmpzum Funktionieren /runbenötigt wurden display :0.0):

systemctl set-default multi-user.target

Ok, das ist alles. Hoffe, das hilft jemandem.

verwandte Informationen