Hallo zusammen,
heute muß ich mal ein Problem anmelden - stehe ziemlich im Wald…
Habe hier Lappi & PC, beide mit EOS & gerade frisch geupdated (schönes Wort…).
Der standard-kernel läuft ohne Probleme, aber wenn ich den LTS starten will, bleiben beide Kisten stehen, wenn das root-fs gemounted werden soll. Ich hatte mich damit zurückgehalten, weil ich von dem dracut-Problem gelesen hatte, aber gestern gesehen, daß da jetzt dracut 108 raus ist, ist bei mir jetzt auch jeweils drauf.
Damit nochmal den LTS-kernel neu gebaut, aber weiter kein Erfolg.
Beim Lappi altes Bild:
Ich kann leider nur die Bilder liefern, denn dann geht nur noch Kaltstart (bei allen).
In den logs in /var habe ich auch nichts gefunden, was mich erhellen könnte.
Bootversuch mit fallback-initrd ging genauso in die Hosen.
Falls das von Belang ist: Ich benutze rEFInd auf allen Maschinen schon länger, solche Probleme kannte ich aber noch nicht.
Wenn logs oder was anderes gebraucht wird, liefere ich das gerne nach, wollte den Roman erstmal halbwegs kurz halten.
P.S. - Den LTS konnte ich genau 1x starten (auf´m Lappi):
Aug 10 16:17:13 AsusWN kernel: Linux version 6.12.40-1-lts (linux-lts@archlinux) (gcc (GCC) 15.1.1 20250425, GNU ld (GNU Binutils) 2.44.0) #1 SMP PREEM>
Auf dem Foto ist ein Fehler zu sehen, der auf einen Fehler bei den Modulen mit der Bezeichnung "dm_mod and dracut-pre-udev” hinweist. Hast du die Festplatten in AHCI oder ist die Festplatte verschlüsselt? ?
Ist nichts verschlüsselt, SSD läuft soweit ich das sehe, in AHCI. Gibts heute überhaupt noch was anders? Gegenüber Standard-Kernel ist absolut nichts verändert.
Noch ein Nachtrag:
Habe gerade ein downgrade dracut auf 106-1 gemacht.
Dabei hat er brav die initrd´s neu gebaut, Resultat aber wie im ersten Bild (beim LTS).
Da ist anscheinend noch ein weiteres Problem unterwegs.
Danke, genau so.
Was müßte ich dracut mitgeben, damit er das macht?
manpage lesen kann ich zur Not aber selber…
P.S. # dracut --list-modules initramfs-linux-lts.img | grep ext liefert kein ext4.
Bin nicht ganz sicher, wo und wonach ich jetzt suchen muß und ob --add-module reicht.
Das siehst du nur wenn das system hochgefahren ist. Der pacman sagt dir das dann.
Hast du den perplexity link gelesen den ich geteilt habe? Dort steht wie du beim kernel auf der cmdline das ext4 forcieren kannst. Einfach mal probieren. Im bootmenu auf edit gehen (drücke ‘e’ auf dem kernel entry) und die cmdline ändern
Sooo, mit dem rd.driver.pre=ext4 hat sich nichts geändert.
Bleibt genau da hängen wie im 1. Bild.
Habe zur Kontrolle das gleiche gemacht mit dem jetzigen Kernel, kommt im Journal an.
Sollte also da auch angekommen sein.
Tja, das habe ich befürchtet.
Ich hatte schon vor einiger Zeit mal das normale Journal mit diesem Ablauf verglichen und kam zu dem Schluß, daß hier wohl der obligate fscheck und dann das mount -a mit der fstab passieren sollte. Dazu passen die beiden UUID´s, die da bei den Sternchen abwechselnd angezeigt werden.
Nur kommt er da wegen irgendwas nicht zu Potte, weil wohl der dracut irgendeinen Mist in die initrd gebastelt hat.
Leider kommt man da ja nicht rein oder ran mit einem log oder sonstwas. Die Kernel-cracks vielleicht, aber nicht unsereiner.
An deiner Stelle würde ich in ein live ISO booten, ein chroot machen, dracut 108_eos-1 installieren und die initrd bzw. die ganze /boot Struktur neu erzeugen lassen.
Ich habe die Installation mit dem ganz normalen ISO gemacht und keinerlei Sonderlocken vorgegeben (bis auf XFCE und OHNE Bootloader - weil ich rEFInd nutze).
Die files liegen bei mir alle in /boot.
Auf dem PC sieht es übrigens genauso aus.
Und wenn der Standard-Kernel läuft (immer!), dann solte der LTS doch auch gehen - hat er ja 1x bewiesen.
Den dracut 108 hatte ich ja schon drauf, ging aber auch nicht.
Notfalls muß ich eben bei dem Standard-Kernel erstmal bleiben, denn ich möchte hier nicht mein “Arbeitspferd” ruinieren. Fühle mich für solche Operationen am offenen Herzen noch nicht sicher genug…
