Emergency Mode durch LUKS und NVIDIA

Hinweis: In dem Thema Emergency Mode durch LUKS und NVIDIA gibt es 170 Antworten auf 18 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
    Zitat von Oriel7

    Danke für alle Hilfe. Die hohe Zahl der Posts liegt daran, daß keiner die Lösung gefunden hat. Irgendwelche Neuerungen sind mit der Kombination Nvidia 1080 und LUKS auf der Homepartition nicht vereinbar. Dazu Google-KI:

    Da hast Du eine Antwort.

    Code
     GNU nano 9.1       /etc/fstab                                                                                          
UUID=c1308ca1-4390-444a-b44e-e7804f191cb7  /          ext4  defaults  0  1
/dev/mapper/cr-auto-5                      /home      ext4  noauto, defaults,   0  2
UUID=7568-2808                             /boot/efi  vfat  utf8      0  2
UUID=954ca640-6844-4560-bfcd-4de567c9d999  swap       swap  defaults  0  0
/dev/mapper/crypthdd1                      /mnt/hdd1  ext4  noauto, defaults,noauto noatime,nofail  0  2
/dev/mapper/crypthdd2                      /mnt/hdd2  ext4  noauto, defaults,noauto noatime,nofail  0  2


    Du trägst in der fstab bei Deinen Crypto Parttionen ein "noauto"das heißt beim Systemstart mounted der syystemd die Platten nicht. Das machst Du manuell und dann werdeen wir sehen was dabei rum kommt.

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329634 haftet ausdrücklich der jeweilige Autor: V-Treiber

    Funktioniert das System, wenn bei der Homepartition noauto steht?


    PS. Für die Nachwelt ein Hinweis. Durch Eure Hinweise habe ich herausgefunden, daß, wenn man LUKS verwendet, man die Homepartition nicht mit der Markierung "linux-home" oder "linux_home" versehen darf, weil sonst beim Booten zweimal versucht wird einzuhängen.


    Einmal editiert, zuletzt von Oriel7 ()

    Für den Inhalt des Beitrages 329635 haftet ausdrücklich der jeweilige Autor: Oriel7

    Zitat von Sauerland

    Dazu hast du dich nicht geäußert.

    Pardon, das hatte ich früher schonmal versucht, denn Google-KI hatte das vorgeschlagen. Hatte damals das Problem nicht gelöst, weil die Paßworteingabe auch im Textmodus nicht glatt lief. Weil im Moment das System zumindest beim vierten Booten starte, will ich nchts mehr ausprobieren, was nicht eine sichere Lösung verspricht. Wir könnten daher den Fall hier auch abschließen. Danke für Eure Hilfe.


    Für den Inhalt des Beitrages 329638 haftet ausdrücklich der jeweilige Autor: Oriel7

    Wenn du das per Hand nur beim Start einträgst, gilt so ein Parameter nur für diesen Start.


    Wenn es funktioniert (mehrmals ausprobieren) , kann man mit update-bootloader es in den Grub permanent eintragen.

    Vermutlich wäre das Problem mit einem Unified Kernel Image (UKI) gelöst. Weiß jemand, ob es dass auch bei OpenSuSE gibt ?


    Zitat

    Ein UKI fasst unter anderem Kernel und Initramfs sowie weitere für den Systemstart benötigte Komponenten in einer einzelnen EFI-Datei zusammen. Bei der Installation richtet TUXEDO OS das UKI als standardmäßigen Boot-Eintrag ein. Die Eingabe des LUKS-Passworts erfolgt dabei über Plymouth und berücksichtigt das während der Installation gewählte Tastaturlayout.


    https://linuxnews.de/tuxedo-os…haelt-uki-unterstuetzung/

    Für den Inhalt des Beitrages 329673 haftet ausdrücklich der jeweilige Autor: rkbwde

    Zumindest gibt es ein Wiki :


    Code
    https://en.opensuse.org/SDB:Static_Initrd_and_Unified_Kernel_Image

    und die Prozedur scheint für Tumbleweed zu funktionieren. Aber ob das das Problem wirklich löst ? :/
    Für mich erscheint die Ursache weder geklärt noch eingegrenzt.

    Einmal editiert, zuletzt von Dachstein ()

    Für den Inhalt des Beitrages 329674 haftet ausdrücklich der jeweilige Autor: Dachstein

    Gefällt mir 1

    Für die Nachwelt möchte ich hier nochmal die von Google-KI vorgeschlagene Lösung festhalten, die das Problem anscheinend bei mir bei OpenSUSE Tumbleweed gelöst hat.

    Das Problem: Ich habe OpenSUSE Tumbleweed installiert, mit LUKS auf der Homepartition, efi-Boot, KDE mit Wayland, NVIDIA 1080 Ti. Beim Hochfahren kommt entweder der Emergency Mode oder der Paßworteingabebildschirm ist eingefroren. (Mit Leap war es ähnlich.)

    Lösung (von Google-KI): „Dieses Problem ist bei openSUSE Tumbleweed ein bekannter Endgegner. Es entsteht, weil das grafische Boot-Menü (Plymouth) versucht, die Passworteingabe für deine /home-Partition anzuzeigen, während gleichzeitig das Kernel-Modul von NVIDIA initialisiert wird. Da Tumbleweed ein extrem schnelles Rolling-Release ist, überholen sich die Prozesse beim Booten (Race Condition): Die Grafikkarte schaltet um, Plymouth stürzt ab, friert ein oder verschluckt Zeichen deines Passworts.“

    „Lösung: Die NVIDIA-Treiber direkt in die Ramdisk (Initramfs) zwingen. Standardmäßig lädt openSUSE die NVIDIA-Treiber erst sehr spät im Bootprozess, damit die Boot-Ramdisk klein bleibt. Zu diesem Zeitpunkt läuft das LUKS-Passwortfenster aber schon. Wenn wir die NVIDIA-Treiber zwingen, sofort beim allerersten Boot-Schritt zu starten (Early KMS), gibt es kein Wettrennen mehr.“

    1. Öffne ein Terminal und erstelle eine Konfigurationsdatei für den Ramdisk-Generator (dracut:(
      Code
      sudo nano /etc/dracut.conf.d/99-nvidia-early-kms.conf
    2. Füge dort folgende Zeile ein, damit die Treiber zwingend mitaufgenommen werden:
      Code
      force_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "
    3. Speichere die Datei (Strg+O, Enter) und schließe sie (Strg+X).
    4. Generiere deine Boot-Ramdisk für alle Kernel neu:
      Code
      sudo dracut -f --regenerate-all

    Vorteil: Plymouth und NVIDIA sind von Sekunde Eins an synchronisiert, die Passworteingabe ist wieder wunderschön grafisch und bricht nicht ab.“


    Für den Inhalt des Beitrages 329716 haftet ausdrücklich der jeweilige Autor: Oriel7

    Danke 1