Kernel nach 6.1.0-9-amd64 booten nicht

[empty_string]

Hallo,

bisher lief Debian testing (ehemals bookworm) auf dem Framework Laptop 13 (i5-1240P) problemlos. Die Umstellung auf trixie erfolgte erst vor kurzem, damit wurden Kernel 6.3.0-1 und diese Woche 6.4.0-1 zu Grub hinzugefügt. Beide booten nicht, Bildschirm bleibt schwarz, kein Passwort-Prompt für die verschlüsselte Platte.
Jetzt bootet lediglich noch

Code: Alles auswählen

uname -a
6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux

Wie fange ich mit der Fehlersuche an?
Eine erste Recherche ergab, dass es mit nomodeset zusammen hängen könnte. Hat da jemand Erfahrung? Gab es da entsprechende Änderungen zwischen den Kernel-Versionen? Wie probiere ich das möglichst so aus, ohne mir die letzte Bootmöglichkeit zu verbauen?

Vielen Dank vorab,
empty_string

[michaa7]

..Bildschirm bleibt schwarz, kein Passwort-Prompt für die verschlüsselte Platte.
...

Das ist eine unzureichende Fehlerbeschreibung ...

du schaltest den Rechner ein
das Grub menü erscheint (?)
kernel xyz ist der oberste der dann auch automatisch gestartet wird (?)
dann (???)

Und für den Beginn lies vllt einfach mal was MSfree in diesem Thread vorschlägt (bezüglich ssh oder bootparametern):
viewtopic.php?t=187442&start=25#p1333910

[empty_string]

Hallo und vielen Dank!

Den bootparameter

Code: Alles auswählen

"intel_iommu=igfx_off" 

habe ich gleich ausprobiert, leider erfolglos (wobei grub-update auch nicht ganz sauber lief, siehe unten).
Außerdem hatte ich im UEFI Secure Boot deaktiviert.

Sorry für die ungenügenden Angaben, ja richtig, das Grub Menü erscheint. Unter "advanced" kann ich 3 Kernel auswählen.

Als default Kernel 6.4.0-1 kommt der Bootvorgang bis hier hin:

Mit Kernel 6.3.0-1 bis hier hin:

(Oder umgekehrt, falls ich das gerade verwechselt habe).

Kernel 6.1.0-9 bootet weiterhin problemlos.

nomodeset wird im Zusammenhang mit Framework Laptops erwähnt, aber das habe ich noch nicht ausprobiert.

Hier das grub update:

Code: Alles auswählen

/usr/sbin/update-grub
Generating grub configuration file ...
Found background image: .background_cache.png
File descriptor 22 (anon_inode:inotify) leaked on vgs invocation. Parent PID 4903: /usr/sbin/grub-probe
File descriptor 22 (anon_inode:inotify) leaked on vgs invocation. Parent PID 4903: /usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-6.4.0-1-amd64
Found initrd image: /boot/initrd.img-6.4.0-1-amd64
Found linux image: /boot/vmlinuz-6.3.0-1-amd64
Found initrd image: /boot/initrd.img-6.3.0-1-amd64
Found linux image: /boot/vmlinuz-6.1.0-9-amd64
Found initrd image: /boot/initrd.img-6.1.0-9-amd64
File descriptor 22 (anon_inode:inotify) leaked on vgs invocation. Parent PID 5408: /usr/sbin/grub-probe
File descriptor 22 (anon_inode:inotify) leaked on vgs invocation. Parent PID 5408: /usr/sbin/grub-probe
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

[empty_string]

Kleines update:

Habe direkt beim Start im Grub Menü die Option "nomodeset" als Bootparameter hinzugefügt mit dem Ergebnis
Kernel 6.3.0-1 bootet jetzt!
Kernel 6.4.0-1 bootet weiterhin nicht.

Und die Option "nomodeset" setzt die Bildschirmhelligkeit massiv runter, ohne dass ich sie wieder ändern könnte, außer wenn ich den Parameter wieder rausnehme.

[michaa7]

Die update-grub fehlermeldungen sind harmlos und eher kosmetisch.

Viel wichtiger: Die screenshots, sind die schon mit bestimmten zusätzlichen bootparametern, oder ist es das was due als "schwarzen bildschirm bezeichnest ... weil es hängen bleibt.

Dann wären da eben bessere beschreibungen sinnvoll wo der bootvorgang hängen bleibt. Ich bin da keine große Hilfe weil ich mich mit der Recherche im journal und bootlog wenig auskenne, aber der Punkt schein ja zu sein dass man finden müßte was konkret hängt. Dazu könntest du dir mal diesen thread anschauen:
viewtopic.php?t=177307
um in den logs mehr und ggf. aussagekräftige infos zu finden.

Viel Erfolg.

[empty_string]

Hallo micha,

vielen Dank für deine Antwort, ich musste eine Weile weiterhin mit dem alten Kernel arbeiten und konnte mich jetzt erst wieder damit beschäftigen.

Kernel 6.3.0.1 wurde mittlerweile beim testing upgrade entfernt, allerdings bootet 6.4.0-1 weiterhin nicht, der obige screenshot ist korrekt. Dort bleibt der Bootvorgang stecken, das meinte ich mit schwarzen Bildschirm, ich hatte lediglich die "quiet" Option entfernt.

Das Problem ist, dass ich nicht an das Bootlog des anderen Kernels komme, journalctl zeigt mir lediglich die Bootvorgänge des funktionierenden Kernels an, also 6.1.0.-9.

Auch funktioniert das Booten im recovery mode des 6.4er Kernels ebenfalls nicht, endet an derselben Stellen, sprich ich komme nicht einmal bis zu Eingabe des Passworts für die verschlüsselte Platte.

Gibt es noch eine andere Möglichkeit oder weitere Kernelparameter, die ich testen könnte?

Mit vielen Dank und Grüßen weiterhin.

[empty_string]

Wenn ich mir den Screenshot oben zu 6.4.0-1 anschaue, dann könnte es doch irgendetwas mit UEFI zu tun zu haben?
Ich habe "Enforce secure boot" deaktiviert aber das ändert nichts. Mit den anderen Optionen "Restore" und "Erase alle" habe ich noch nicht rumgespielt, wollte mir dadurch nicht die letzte Bootmöglichkeit verstellen.

Any ideas?

[empty_string]

Ich kann leider nicht nachvollziehen wieso, aber mit dem letzten testing update des Kernels auf 6.4.0-3 bootet der Rechner wieder!