Beiträge von Oriel7

  • Emergency Mode durch LUKS und NVIDIA

    [Korrektur, da --no-hostonly falsch war, habe ich es durch --hostonly ersetzt]:

    Mein PC: OpenSUSE Leap 16.0, efi, LUKS auf /home, Grub-Boot, Nvidia GeForce GTX 1080 Ti.

    Vorhin führte das Booten meistens zum Emergency Mode. Dann tat ich:

    * Die Markierung „linux-home“ der Homepartition habe ich durch "no_automount" ersetzt. (Erläuterung von Google-KI: "Das Subsystem systemd-homed versucht unter modernen Linux-Distributionen oft, verschlüsselte Home-Verzeichnisse auf eine neue Art zu verwalten, was sich massiv mit klassischen /etc/crypttab-Einträgen beißt.")

    * Dann sudo dracut -f --no-hostonly.

    * Dann in /etc/default/grub GRUB_DISABLE_OS_PROBER="true" gesetzt.

    * Dann sudo grub2-mkconfig -o /boot/grub2/grub.cfg.


    Beim ersten Booten konnte ich auf dem Paßwortbildschirm zwar nichts eingeben, aber immerhin waren im journal alle Fehlermeldungen weg. Mal sehen, ob jetzt das Problem wirklich mal verschwindet. Auch auf einem anderen Rechner, auf dem Tumbleweed läuft, kann man manchmal beim Booten auf dem Paßwortbildschirrm nichts eingeben. Man glaubt es nicht, wie schwer Opensuse sich mit einer mit LUKS verschlüsselten Homepartition tut.

  • Emergency Mode durch LUKS und NVIDIA

    Mein PC: OpenSUSE Leap 16.0, efi, LUKS auf /home, Grub-Boot, Nvidia GeForce GTX 1080 Ti.

    Vorhin führte das Booten meistens zum Emergency Mode. Dann tat ich:

    * Die Markierung „linux-home“ der Homepartition habe ich durch "no_automount" ersetzt. (Erläuterung von Google-KI: "Das Subsystem systemd-homed versucht unter modernen Linux-Distributionen oft, verschlüsselte Home-Verzeichnisse auf eine neue Art zu verwalten, was sich massiv mit klassischen /etc/crypttab-Einträgen beißt.")

    * Dann sudo dracut -f --no-hostonly.

    * Dann in /etc/default/grub GRUB_DISABLE_OS_PROBER="true" gesetzt.

    * Dann sudo grub2-mkconfig -o /boot/grub2/grub.cfg.


    Seitdem kann ich beim Paßwortbildschirm meistens nichts eingeben. Manchmal startet das System dann doch.

    Code
    sudo journalctl -xb -2 -p err
Journal file /var/log/journal/a15d9aad2abb4e7b990418fe6bce7313/system@00065b22b7a46566-2c156e9f89009181.journal~ is truncated, ignoring file.
Sep 10 17:36:33 localhost kernel: x86/cpu: SGX disabled or unsupported by BIOS.
Sep 10 17:36:33 localhost 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
Sep 10 17:36:33 localhost 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
Sep 10 17:36:38 localhost kernel: 
Sep 10 17:37:01 localhost (udev-worker)[970]: vboxdrv: /usr/lib/udev/rules.d/60-vboxdrv.rules:1 Only network interfaces can be renamed, ignoring NAME="vboxdrv".
Sep 10 17:37:01 localhost (udev-worker)[973]: vboxdrvu: /usr/lib/udev/rules.d/60-vboxdrv.rules:2 Only network interfaces can be renamed, ignoring NAME="vboxdrvu".
Sep 10 17:37:01 localhost.localdomain (udev-worker)[970]: vboxnetctl: /usr/lib/udev/rules.d/60-vboxdrv.rules:3 Only network interfaces can be renamed, ignoring NAME="vboxnetctl".

  • Emergency Mode durch LUKS und NVIDIA

    * Ah ja klar, über die fstab, das wußte ich eigentlich.
    * Hatte mich vorhin geirrt, die Homepartition trägt doch die Markierung "linux-home". Diese habe ich durch "no-automount" oder so ähnlich ersetzt.

    * Erläuterung von Google-KI: "Das Subsystem systemd-homed versucht unter modernen Linux-Distributionen oft, verschlüsselte Home-Verzeichnisse auf eine neue Art zu verwalten, was sich massiv mit klassischen /etc/crypttab-Einträgen beißt."

    * Dann sudo dracut -f --no-hostonly.

    * Dann in /etc/default/grub GRUB_DISABLE_OS_PROBER="true" gesetzt.

    * Dann sudo grub2-mkconfig -o /boot/grub2/grub.cfg.


    Ergebnis: Ich lief seitdem nicht mehr in den Emergency-Mode, dafür kann ich aber 4 von 5 Mal im Paßwortbildschirm nichts eingeben. Problem also nicht wirklich gelöst.

  • Emergency Mode durch LUKS und NVIDIA

    Google-KI: „Das Journal zeigt die Ursache sehr genau: Der RAM ist in Ordnung, aber Ihr System läuft in eine Race Condition beim Entschlüsseln der /home-Partition. Der entscheidende Fehler lautet: Cannot use device [...] which is in use (already mapped or mounted). Das bedeutet: Das System versucht, das LUKS-Gerät unter dem Namen cr-auto-5 ein zweites Mal zu entschlüsseln, obwohl es im Hintergrund (oft durch das initiale Boot-Skript in der Initramfs) bereits erfolgreich geöffnet wurde. Da zwei Prozesse gleichzeitig auf dasselbe Krypto-Gerät zugreifen wollen, sperrt sich das System selbst aus (Device or resource busy), bricht ab und wirft Sie in den Emergency Mode. Bei openSUSE Leap in Kombination mit einer NVIDIA-Grafikkarte passiert dies häufig, weil der Passworteingabe-Bildschirm (Plymouth) und die systemd-Dienste durch die Treiber-Verzögerung zeitlich asynchron geladen werden.“

    Empfehlung: „Wir müssen die Initramfs (das Start-Abbild) neu bauen, damit systemd beim Booten genau weiß, wie die Krypto-Geräte zugeordnet sind, und keine doppelten Zuordnungen versucht. Bauen Sie die Initramfs mit folgendem Befehl neu auf, um die aktuelle Hardware- und Krypto-Konfiguration fest einzubrennen:

    sudo dracut -f --hostonly “

  • Emergency Mode durch LUKS und NVIDIA

    Google-KI meint zu der Meldung "e820: update [mem 0x00000000-0x00000fff] usable ==> reserved": „Diese Meldung ist eine vollkommen normale und harmlose Kernel-Nachricht beim Systemstart. Sie bedeutet kurz gesagt: Der Linux-Kernel korrigiert eine Angabe des Mainboard-BIOS, um das System vor potenziellen Datenfehlern oder Abstürzen zu schützen.“

  • Emergency Mode durch LUKS und NVIDIA

    Zitat von V-Treiber

    Deswegen der Hinweis auf den thermischen Fehler, wenn Du wirklich sporadische Speicher-Fehler hast, hilft nur eine Dauerschleife. Wenn der Dauertest nichts bring, weißt Du schon mal, das ist nicht das Problem, Ausschlussverfahren.

    Moment, ist denn "e820: update [mem 0x00000000-0x00000fff] usable ==> reserved" überhaupt eine mögliche Ursache für den Emergency Mode und ist es ein Hinweis auf einen Hardwarefehler?

  • Emergency Mode durch LUKS und NVIDIA

    memtester hat gerade keinen Fehler im RAM gefunden. memtest werde ich auch noch laufen lassen, aber entscheidend sind wahrscheinlich doch die Fehlermeldungen der Form "Failed to activate with specified passphrase: Device or resource busy". Wie kann ich die beheben? Wahrscheinlich liegt es immer noch an LUKS und NVIDIA. Google KI hatte mir folgendes Vorgehen empfohlen:

    Code
    echo 'force_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "' | sudo tee /etc/dracut.conf.d/nvidia.conf

    Dann in Grub "nvidia-drm.modeset=1" hinzufügen und "sudo sdbootutil update" durchführen. Wäre das zielführend? Es übersteigt meine Kompetenz.

  • Emergency Mode durch LUKS und NVIDIA

    (System: OpenSUSE Leap 16.0, efi, LUKS auf /home, Grub-Boot, Nvidia GeForce GTX 1080 Ti)
    Leider kehrt der Emergency Mode immer wieder zurück. Manchmal erscheint beim Booten der Paßworteingabebildschirm, aber ich kann nichts eingeben, keine Punkte erscheinen. Manchmal erscheint er, aber nach der Paßworteingabe gelange ich in den Emergency Mode. Und in seltenen Fällen startet das System. Kann es sein, daß noch ein ganz anderer Fehler besteht, z.B. defekte RAM? Vorhin im Emergency mode habe ich mit journalctl Fehlermeldungen der Form "e820: update [mem 0x00000000-0x00000fff] usable ==> reserved" und "e820: remove [mem 0x000a0000-0x000fffff] usable" gefunden, aber die finde ich jetzt nicht mehr, sondern mehrere Fehlermeldungen der Form "Failed to activate with specified passphrase: Device or resource busy":