Results 1 to 5 of 5

Thread: Sytemstart steckt im emergency mode fest

  1. #1

    Default Sytemstart steckt im emergency mode fest

    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.

    Code:
    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.
    Code:
    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. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    31,742

    Default Re: Sytemstart steckt im emergency mode fest

    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
    Code:
    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
    Code:
    mount | grep sda6
    Und steht da wirklich /home?

    Das alles so das wir sicher sind das was du sagst auch stimmt
    Henk van Velden

  3. #3

    Default AW: Sytemstart steckt im emergency mode fest

    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.
    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.
    Code:
    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 


    Code:
    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. #4
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    31,742

    Default Re: Sytemstart steckt im emergency mode fest

    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.
    Henk van Velden

  5. #5

    Default AW: Sytemstart steckt im emergency mode fest

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

    # man fsck.xfs

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •