Ich habe heute eine frische Installation von Tumbleweed (kernel 6.5.8-1) und Leap 15.5 (5.14.21-150500.55.31) auf einer sauberen SSD versucht, aber beide frieren beim ersten Reboot bei “Loading Initial Ramdisk” ein. Ich kann keinen Fehler in den config Dateien finden und auch die korrekten Partitionen sind im grub2 gelisted. Die Installation selbst läuft fehlerfrei und alle Partitionen und configs scheinen sauber zu sein. Die üblichen kernel parameter Variationen beheben das Problem nicht und auch verbose output liefert keinen zusätzlichen Output. Ich benutze auf diesem System ein gut gewartetes Leap 15.2, aber es ist Zeit für ein Update (Intel I7-5930K, 128GB RAM, Gigabyte X99-SLI, 4TB Samsung 990PRO).
Für Vorschläge, was ich noch versuchen könnte, wäre ich sehr dankbar.
Ich wollte zunächst die verbosity erhöhen, also kein “splash” / “quiet” dafür z.B. “debug” “earlyprintk”. Kein zusätzlicher Output wird generiert. Ich hatte gelesen, dass es manchmal mit dem microcode loader zusammenhängt, also mal “dis_ucode_ldr” probiert. Obwohl es kein Laptop ist, acpi=off / on. Dann z.B. nomodeset und auch alle mitigations=off; mit und ohne secure boot. Wenn ich irgendwie herausfinden könnte an welcher Stelle initrd hängt, würde das vielleicht einen Hinweis geben. Mit einem autarken USB kann die SSD ohne Probleme gemountet werden und ich kann keine Probleme in grub.cfg sehen. Das initrd file scheint okay (e.g. via lsinitrd), aber ich bin schon länger kein Kernel/Boot/Ramdisk Experte mehr, da ich bestimmt 15 Jahre nur noch stock-kernels verwende and nicht mehr optimiere.
Gibt es einen Weg den “Intial Ramdisk” Prozess verbose zu bekommen und zu sehen, wo es genau hakt?
Das Mainboard BIOS ist das neueste verfügbare, allerdings auch über 5 Jahre alt. Dieses Problem scheint viele andere Distributionen ebenfalls zu betreffen, scheint also fundamentaler und vermutlich Hardware abhängig zu sein, da es ja sehr viele andere Nutzer gibt, die scheinbar ohne Probleme updaten.
Ich würde zunächst an dem einen Desktop debuggen, aber übrigens habe ich auf meinem <2 Jahre alten Thinkpad Laptop auch das Problem, dass ein zypper -dup Update von Leap 15.3 auf 15.4. dann nicht mehr bootet und ich zum vorhergehenden Snapshot zurückfallen muß. Auf allen meiner Computer sind Leap 15.1/15.2/15.3 die letzten Opensuse Distributionen, die fehlerfrei booten. Das Problem ist, dass der Wartungsaufwand gerade mit 15.1./15.2 aufgrund des end-of-life Statuses schlicht zu groß ist und ich deshalb alle Systeme idealerweise auf Tumbleweed updaten möchte.
acpi=off, nomodeset und so hast du ja schon getestet, also was mir als erstes in den Sinn gekommen wäre. initcall_debug scheint mir noch interessant zu sein.
So wie ich das lese dropst du ja nicht in eine emergency-shell, oder? Falls doch wäre das Zitat aus der dracut-man-page noch interessant:
If you are dropped to an emergency shell, while booting your
initramfs, the file /run/initramfs/rdsosreport.txt is created,
which can be saved to a (to be mounted by hand) partition
(usually /boot) or a USB stick. Additional debugging info can be
produced by adding rd.debug to the kernel command line.
/run/initramfs/rdsosreport.txt contains all logs and the output
of some tools. It should be attached to any report about dracut
problems. dracut(8) - Linux manual page
Könntest du vielleicht noch deine Hardwareinfo (inxi -Fz oder so) noch posten?
Vielleicht fällt ja jemandem der mitliest noch was ein/auf…
@404_UsernameNotFound sorry für die späte Rückmeldung. Ich hatte im englischen Forum zum Thema geschrieben und bisher auch dort keine erfolgreiche Lösung erhalten. Die debug Optionen helfen nicht weiter. Nichts wird geposted. Das System hängt beim “Booting a command list; Loading Linux 6.5.9-1 default …; Loading initial ramdisk”. Ich habe initrd mit dracut auch bereits nochmal erstellt, aber keine Veränderung. Ich komme nicht einmal in den rescue mode. Der hängt sich auch bei der ramdisk auf. Das letzte Suse, dass sich frisch installieren läßt ist Leap 15.3. Auch bei 15.4 tritt das Problem auf.
Danke, ich hab mir den Thread gerade durchgelesen. Sind ja schon viele Infos drin, wenn auch kein Erfolg bisher. Das mit der esp als DOS (ich denke mal es ist das FAT32-format gemeint) Partition ist meiner Meinung nach eigentlich immer der Fall, auch bei anderen Distros.
Ich habe jetzt mal drüber nachgedacht, was bei openSUSE anders ist als bei anderen Distros und das auch auf dem live-USB-ISO. Gelandet bin ich gedanklich beim filesystem. Läuft eine der Distros die live oder als Installation bei dir laufen auch standardmäßig auf BTRFS? Bzw. hattest du mal versucht eine Installation mit ext4 oder so zu machen? Ich kann mir zwar noch keinen Reim drauf machen, aber ich dachte ich werfe das mal ein.
Benutzen andere Distros, die bei deinem Rechner funktionieren auch dracut?
Ja, ich dachte auch schon an brtfs, da Suse da oft Probleme macht, aber auch mit ext4 das gleiche Resultat. Ich kann Leap 15.3 mit brtfs frisch installieren und ohne Probleme booten. 15.4 frisch installiert friert auch ein und nach einem 15.3->15.4 upgrade mittels zypper dup friert es dann auch ein. Deshalb liegt die Vermutung nahe, daß sich das Problem beim Übergang von 15.3->15.4 eingeschlichen hatte und nun bei 15.5/Tumbleweed noch vorhanden ist.
Ich bin mir nicht sicher, ob MX Linux, das ich mal schnell gegriffen hatte, weil es nun recht populär zu sein scheint, dracut per default nutzt—ich glaube nein—, aber Leap 15.3 nutzte bereits dracut und das booted problemlos. Ich hatte ein solches Problem vor einigen Jahren mit der Leap 42.x Serie schon einmal und blieb dann lange bei 13.x, aber dann funktionierte es irgendwann; das war aber ein anderer Computer auf dem ich zur Zeit auch noch Leap 15.2 fahre. Da dieser meinen 150TB cluster verwaltet, will ich erst dieses Problem lösen, bevor ich mich an den anderen Rechner mache.
Ich hatte überlegt, mal Fedora zu installieren und zu sehen, ob das läuft. Redhad/Fedora nutzen auch dracut. Da ich aber ausschließlich Suse Varianten seit über 20 Jahren als HauptOS nutze, möchte ich eigentlich nicht unbedingt die Distribution wechseln, auch wenn Suse seit einigen Jahren leider nicht mehr so stabil und bug-free out-of-the-box läuft wie früher. Es ist schade, dass es im Ranking vielleicht auch deshalb konstant fällt.
Das hört sich vernünftig an Fedora zu testen (wegen dracut), am besten mit btrfs.
Noch eine Frage: Nutzt du irgendeine Form von Verschlüsselung? LUKS oder so? Das könnte schon auch Auswirkungen auf die Funktionalität vom initramfs haben.
Du meinst auf Distrowatch? Daran kann man m.E. nach nicht die Beliebtheit ablesen… Zufriedene Nutzer werden denke ich eher nicht auf Distrowatch gehen und ihre eigene Distro anklicken.
Bisher finde ich openSUSE sehr komfortabel und stabil, aber ich nutze es jetzt auch noch nicht so lange.
Ich hatte gerade noch mal versucht nachzulesen welche Änderungen es beim Übergang von 15.3 auf 15.4 gab. Mir ist dabei nur der Nvidia-Treiber wirklich aufgefallen. Du nutzt eine gtx 980ti, oder?
Im Grunde glaube ich eigentlich nicht, dass das derartige Auswirkungen auf das initramfs haben sollte, aber vielleicht könntest du ja nochmal versuchen mit nouveau zu installieren anstatt dem proprietären Treiber…
Die Theorie mit dem Nvidia Treiber ist absolut nicht schlüssig in sich selbst. Die Nvidia Repos müssen händisch durch den Nutzer (nach erfolgreicher Installation des OS) hinzugefügt und die Treiber manuell zur Installation ausgewählt werden. Jedoch lässt sich beim TO noch nicht einmal das Basissystem nach Installation von Leap 15.5 oder Tumbleweed booten…
Besser keine wilden Theorien streuen, da das nur den Thread verwässert und absolute Verwirrung stiftet…
Ich habe selbst keine Nvidia-Karte, dachte aber, dass die proprietären Treiber der default sind bei der Installation?
Zugegebener Maßen ist das tatsächlich nicht wirklich schlüssig… Die meisten wirklich schlüssigen Sachen wurden aber auch schon versucht (in dem englischen Thread).
Im Anbetracht der Tatsache, dass Du anscheinend eine ganze Reihe von Systemen auf Deinem Rechner installiert hast/hattest wäre es sehr hilfreich, wenn Du das Ergebnis von
efibootmgr -v
hier zeigen könntest (wurde im englischsprachigen Beitrag auch schon angefragt).
Weiterhin wäre es noch wichtig zu wissen, wieviele ESPs auf Deinem System vorhanden sind. Zeige dazu bitte das ungekürzte Ergebnis von
@susejunky Nein. Es handelt sich um eine frische Installation auf einer eigenen SSD, die bei jedem OS Versuch frisch formatiert und partitioniert wird, und unabhängig von der alten Leap 15.2 Installation auf einer anderen SSD, die ich physisch abhänge, ist. Ich nutze keine parallelen OS und plane die 15.2 SSD in Rente zu schicken.
Ich habe mich dann von Tumbleweed->15.5->15.4->15.3 nur systematisch heruntergehangelt, um herauszufinden, wann das Problem zuerst auftrifft; dies ist beim Übergang von 15.3 zu 15.4 der Fall. Da ich eigentlich Leap bis auf Kernel-Updates wie eine rolling distribution verwende, wollte ich nun gleich Tumbleweed installieren, aber das scheitert leider. 15.5. wäre auch akzeptabel, da ich sowieso noch nicht ganz sicher bin, wie stabil Tumbleweed in einem produktiven System wäre.
@404_UsernameNotFound da das System bei initrd einfriert, also bevor ein NVIDIA Treiber greifen würde, postuliere ich mal, dass das damit nichts zu tun hat.
Ich benutzte/benutze beim Test keine Verschlüsselung. Ersteinmal soll es so laufen.
Und Du hast auch überprüft, dass bei der OS-Installation eine eigene ESP angelegt und mit einem GRUB2/shim-Bootloader (passend zu OS-Version) bestückt wird und dieser auch korrekt im NVRAM Deines UEFIs eingetragen ist und die Boot-Reihenfolge auch entsprechend angepasst wurde?
Wie setzt Du das “physisch abhängen” konkret um (S-ATA-Kabel abziehen, Stromkabel abziehen Komplettausbau bei M.2, …)?
@susejunky Ja, Komplettausbau der M2 SSD, da ich nur einen Slot habe und die neue SSD diesen dann braucht. Das System hat noch mehrere XFS Datenplatten, die zunächst nicht gemounted werden. Inzwischen möchte ich das System erstmal mit der automatischen Partitionierung installieren. Da Leap 15.5 Live auf diesem Computer auch nicht booted und genauso während initrd einfriert, während es auf meinem Thinkpad bootet, gehe ich davon aus, dass es irgendeine Hardware Komponente ist, deren Treiber nicht sauber geladen wird. Daher wäre es toll, wenn man initrd irgendwie zu mehr verbosity überreden könnte, um zu sehen, an welcher Stelle es denn hängt.
Auch wenn diese Platten nicht eingehängt werden, so besteht doch die Möglichkeit, dass sie ESPs beinhalten und diese im NVRAM Deines UEFIs vermerkt sind.
Da Du laut Deinem Beitrag #1 openSUSE Tumbleweed installieren wolltest, hast Du sicherlich auch noch das zugehörige Installationsmedium parat. Von diesem könntest Du das Rescue-System starten und die in #17 genannten Daten ermitteln.
Oder hast Du einen bestimmten Grund aus dem heraus die gewünschten Daten nicht zeigen willst?
@susejunky Nein, die Platten sind reine Datenplatten und enthalten keinerlei EFI oder Legacy Boot Partition, selbst wenn, wäre das egal, da der korrekte Grub2 Eintrag gewählt wird. Das Tumbleweed Rescue System bootet ebenfalls nicht, wie wir im Englischen Forum besprochen hatten. Mit Leap 15.5’s rescue system komme ich rein. So habe ich auch versucht das initrd image neu zu bauen (nach chroot Prozess), was das Problem nicht behoben hat.
Es handelt sich um eine einzige, vollständig zur Verfügung stehende M2 SSD. Die Installation läuft fehlerfrei, aber der erste Bootprozess scheitert während initrd und es bedarf eines harten resets.