Sytemstart steckt im emergency mode fest

Deutsch (German) Installation/Administration
1

Hallo,

ich habe hier einen x64-Rechner mit Tumbleweed auf relativ aktuellem Stand (Kernel ist 5.18.11-1-default), welcher beim Systemstart seit 30.08. im emergency mode landet.
Bei der Ursachenforschung finde ich verschiedene Dinge, weiß nur nicht so recht, was davon ausschlaggebend ist und wie ich es beheben könnte.

journalctl -b 0 -p err
Aug 31 11:12:50  kernel: x86/cpu: SGX disabled by BIOS.
Aug 31 11:12:50  kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x201] vs fed40080 f80
Aug 31 11:12:50  kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x201] vs fed40080 f80
Aug 31 09:12:52  systemd-udevd[564]: /etc/udev/rules.d/40-libsane.rules:41 Unknown group 'scanner', ignoring
Aug 31 09:12:52  systemd-udevd[564]: /etc/udev/rules.d/40-libsane.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Aug 31 09:12:52  systemd-udevd[564]: /etc/udev/rules.d/S99-2000S1.rules:41 Unknown group 'scanner', ignoring
Aug 31 09:12:52  systemd-udevd[564]: /etc/udev/rules.d/S99-2000S1.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Aug 31 09:12:53  systemd-fsck[628]: fsck failed with exit status 4.
Aug 31 09:12:53  systemd[1]: Failed to start File System Check on /dev/disk/by-uuid/17f1af69-77d3-43b2-b2b9-e43fdd4551c0.

(Abgetippt, da kein Netzwerk verfügbar, hoffentlich ohne Fipptehler.)

Der Zeitsprung hat mich zunächst etwas irritiert, meine Vermutung ist, dass hier zwischen local time (+0200) und UTC gesprungen wird und die Einträge dennoch von oben nach unten den chronologischen Ablauf darstellen.

Evtl. mit Bezug zu der Firmware-Meldung finde ich unter yast im journal die folgende Meldung. Da der Kernel noch nicht auf einem aktuelleren Stand als oben genannt ist, glaube ich aber weniger, dass zu dem Zeitpunkt des Journaleintrags ein Update stattgefunden hat.

Aug 30 18:40:57  kernel  microcode: microcode updated early to revision 0xf0, date = 2021-11-12

Den udev-rules würde ich im aktuellen Zusammenhang gerade weniger Gewicht beimessen(?).

Der fsck-Fehler bezieht sich auf /dev/sda6, was /home als mountpunkt hat und ein ext4 Filesystem auf einer SSD ist.
fsck manuell angestoßen liefert die Meldung, dass die Partition gemounted sei.
umount von /dev/sda6 schlägt jedoch fehl, das Zielsystem sei in Benutzung.

Danke schonmal vorab für jegliche Hilfestellung hierbei!

2

Ich möchte nicht fragen nach zuviel Abtipperei. Aber trotzdem möchte ich wissen:

Wie hast du hearusgefunden das uuid= zeigt auf /dev/sda6? Etwa mit

ls -l /dev/disk/by-uuid/17f1af69-77d3-43b2-b2b9-e43fdd4551c0

Wegem Abtippen, bitte nur bestätigen.

Weil es mich wundert das ein Dateisytem das nicht sauber ist (laut fsck) trotzdem ge-mounted ist, kannst du das kontrolieren mit

mount | grep sda6

Und steht da wirklich /home?

Das alles so das wir sicher sind das was du sagst auch stimmt :wink:

3

Hallo,

danke, das hat mir die Tomaten von den Augen genommen!
Ich bin tatsächlich bei “ls -l /dev/disk/by-uuid” in der Zeile verrutscht. :shame:
Die uuid gehört zu /dev/sda7 und der mountpunkt davon laut fstab ist /home. /dev/sda6 ist / und da kann ich lange ein fsck drauf versuchen.

cat /etc/fstab
UUID=f2c8e084-...  /   ext4   defaults    0  1
UUID=787C-...   /boot/efi  vfat  utf8  0  2
UUID=17f1af69-77d3-43b2-b2b9-e43fdd4551c0  /home  ext4  data=ordered  0  2
UUID=0142a7c0-...  swap  swap  defaults  0  0
UUID=F8601...  /daten  ntfs  users  0  0 

mount | grep /dev/sd
/dev/sda6 on / type ext4 (rw,relatime)
/dev/sda2 on /boot/efi type vfat (...)
/dev/sdb2 on /daten type fuseblk (...)

Wenn ich nun fsck auf /dev/sda7 ausführe, meldet er mir nach und nach verschiedene Fehler:
Sechs Inodes, die Teil der liste verwaiser Inodes waren. Repariert.
Unterschiede in der Block-Bitmap. Repariert.
3x Anzahl freier Blöcke in Gruppe #… falsch. Repariert.
Anzahl freier Blöcke ist falsch. Repariert.
Unterschiede in der Inode-Bitmap. Repariert.
2x Anzahl freier Blöcke in Gruppe #… falsch. Repariert.
Anzahl freier Blöcke ist falsch. Repariert.

Anschließend mit “exit” den emercency mode verlassen, daraufhin startete der Rechner normal in das graphische System und lies sich auf den neuesten Stand aktualisieren und problemlos rebooten.

4

Gratuliere!

Anscheinend ist doch was passiert auf dieses Dateisystem. Power outage?

Aber jedenfalls, der Kiste läuft wieder und hoffentlich ist beim Reparieren nichts verloren gegangen.

5

Und wer sich nicht mit fsck beim Rechnerstart rumärgern will, der wechselt zu einem robusteren Dateisystem wie XFS. Siehe:

man fsck.xfs