Emergency Mode durch LUKS und NVIDIA

Gibt es irgendwelche Hinweise darauf, das meine Schwierigkeiten irgendetwas mit Wayland zu tun haben?

Ah, das Flackern habe ich auch! Also werde ich mal das Xfce-X11-Pattern intallieren und das nächste Mal - wenn ich nicht im Emergency-Mode lande - mit X11 starten.

Hier nochmal Google-KIs Meinung zur Ursache:

„

Bei Tumbleweed passiert folgendes:

1. Das System bootet und der Kernel stellt fest: "Ich habe eine NVIDIA-Karte, ich brauche den proprietären Treiber."
2. Gleichzeitig stellt das System fest: "Halt, die /home-Partition (oder das LVM) ist mit LUKS verschlüsselt, ich brauche sofort das Passwort!"
3. Da Tumbleweed extrem schnell bootet, kollidieren diese beiden Anfragen. Das System schaltet auf die grafische Passwortabfrage (Plymouth), bevor der NVIDIA-Treiber initialisiert ist. Das Ergebnis: Die Grafikkarte schaltet ab (schwarzer Bildschirm), während das System im "Blindflug" auf Ihr Passwort wartet.

_______________________

Dass dieser Fehler bei Ihnen (NVIDIA + LUKS + LVM) unter Tumbleweed immer wieder auftritt, liegt an der Einführung von drei gravierenden Neuerungen im Linux-Unterbau der letzten Jahre:

1. Die Einführung von SimpleDRM und der Wegfall von FBDEV

Früher nutzte Linux ein sehr simples Grafik-Subsystem (fbdev), um beim Booten Text anzuzeigen. Der Kernel reichte die Textkonsole einfach an die Grafikkarte weiter, bis der NVIDIA-Treiber übernahm.

• Die Neuerung: Moderne Kernel nutzen SimpleDRM (Simple Direct Rendering Manager). Dieses System versucht, sofort nach dem GRUB-Menü eine hochauflösende, grafische Umgebung für die Passwortabfrage bereitzustellen. [1, 2]
• Das Problem: Der proprietäre NVIDIA-Treiber ist zu diesem Zeitpunkt noch gar nicht geladen. SimpleDRM versucht, die Kontrolle an die GTX 1070 zu übergeben, scheitert am proprietären Code, und das Videosignal bricht ab. [2]

2. Der Wechsel von mkinitrd zu dracut

Früher hat openSUSE beim Erstellen des Boot-Images (initrd) sehr aggressiv fast alle verfügbaren Grafikmodule blind mit hineingepackt.

• Die Neuerung: Das moderne Tool dracut arbeitet extrem modular und versucht, das Boot-Image so schlank und schnell wie möglich zu halten.
• Das Problem: Da der NVIDIA-Treiber proprietär ist und aus rechtlichen Gründen nicht direkt im Kernel steckt, stuft dracut ihn standardmäßig als "extern" ein und lässt ihn aus dem initialen Boot-Image weg. Er wird auf "Late KMS" (spätes Laden) gesetzt. Da Ihr LUKS-Passwort aber sofort gebraucht wird, stoppt der Bootvorgang genau in der Sekunde, in der kein Grafiktreiber aktiv ist. [1]

3. Die rasanten Kernel-Sprüngen in Tumbleweed

Als Rolling Release springt Tumbleweed wöchentlich auf die neuesten Kernel-Versionen (z. B. von Kernel 6.x auf 7.x). [3]

• Das Problem: NVIDIA hinkt mit seinen Treiber-Updates den allerneuesten Kernel-Entwicklungen oft Tage oder Wochen hinterher. Bei jedem großen Kernel-Update bricht das vorkompilierte Kernel-Modul (kmp-default). Während ein System ohne Verschlüsselung dann einfach in eine hässliche Textzeile bootet, verhungert ein verschlüsseltes System im schwarzen Bildschirm, weil das Anzeigegerät für die Passworteingabe abstürzt. [1, 2, 3, 4]

Warum openSUSE das nicht einfach "repariert"

openSUSE (und auch andere Distributionen wie Fedora) können das rechtlich und technisch nicht pauschal im Installer automatisieren:

1. Rechtliche Lizenzkonflikte: Da der NVIDIA-Treiber Closed-Source ist, darf openSUSE ihn nicht standardmäßig auf dem Installationsmedium mitliefern oder ungefragt tief in das Kern-System (initrd) einbacken.
2. Die Open-Source-Philosophie: Die Entwickler setzen darauf, dass NVIDIA irgendwann den quelloffenen Treiber (nvidia-open) für ältere Karten perfektioniert. Das Problem: Der neue Open-Source-Treiber von NVIDIA unterstützt Ihre GTX 1070 (Pascal-Architektur) nicht vollständig – er ist erst ab der RTX-2000er-Serie (Turing) stabil. Besitzer älterer GTX-Karten sind dauerhaft auf den proprietären Treiber angewiesen und fallen durch das Raster. [3, 4, 5]

Fazit

Ihr Setup benötigt zwingend die manuelle Brücke (Early KMS via dracut), um der Automatisierung mitzuteilen: "Warte mit der LUKS-Abfrage, bis der NVIDIA-Treiber bereit ist." Da Leap 16.0 den Kernel deutlich seltener und konservativer aktualisiert, bleibt Ihnen dieser treiberbedingte Blindflug dort im Alltag erspart. [1, 6]