• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst Installation der Leap 15.6. legt die parallel laufende 15.5 lahm

Hallo,

ich bin heute in folgender Sackgasse gelandet.

Wie schon viele Jahre zuvor installiere ich neue Leap-Versionen immer auf zwei Ext4-Partitionen (/ und /home), die von dem aktuell laufenden System unabhängig sind. Dieses ältere System betreibe ich typischerweise noch einige Zeit weiter als "Rückversicherung", bevor ich mich selbst (und meine Familie) endgültig zur neuen Installation hinübertransferiere.

So war es auch heute. Ich habe meine seit Monaten reibungsfrei laufende Leap 15.5 heruntergefahren, von einem Stick mit den Installationsdateien der 15.6 neu gebootet und letztere auf zwei freie Partitionen installieren lassen. Der Grub2 kam in den MBR - wie schon früher immer praktiziert. Die jungfräuliche 15.6 lief danach störungsfrei hoch. So weit, so gut.

Der YaST in der 15.6 hat unter 'Bootloader-Optionen, [X] Fremdes OS testen' das 15.5-System erkannt. Ich habe die "Zeitüberschreitung in Sekunden" ein wenig heruntergesetzt und den Grub2 neu schreiben lassen. Beim folgenden Neustart wurde die 15.5 auch korrekt angeboten. Der Versuch, die 15.5 dann auch hochzufahren, endete aber in der Meldung:
You are in emergeny mode. After logging in, type "journalctl -xb"
to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Administratorpasswort f?r Wartungszwecke eingeben
(oder dr?cken Sie Strg+D, um fortzufahren:)
Richtig, exakt diese Meldung haben schon viele Leute zu Gesicht bekommen. Keine der im Internet beschriebenen Erklärungen oder Lösungsmöglichkeiten hat mich aber weitergebracht.

Weiterhin konnte ich den PC über die SystemRescue-11.00 von einem Stick aus starten lassen. Die root-Partition der 15.5 (wie jene der 15.6 natürlich) wurde gefunden. Ein Startversuch von dort endete jedoch in derselben Fehlermeldung wie oben zitiert. Damit schließt sich der Kreis.

Eine Sache könnte dennoch weiterhelfen. Der Startversuch der 15.5 aus der SystemRescue heraus lieferte jede Menge log-Zeilen. Eine davon lautete:
[FAILED] Failed to start Load Kernel Modules.

Was ich hiermit anfangen könnte, weiß ich nicht. Mir sind inzwischen die Ideen ausgegangen. Was kann ich tun? Welche Information kann ich noch hier einstellen?

Pirx
 
Ich hätte schwören können, dass ich dieser Maschine nie etwas anderes als den Legacy Mode betrieben habe.

Was mich unsicher macht: Das angehängte Bild zeigt eine Ausgabe von 'gparted'. Darin taucht eine Partition der Größe 1.00 MB auf mit der Beschreibung "nicht zugeteilt", die mir früher nie aufgefallen ist. Könnte das eine heiße Spur sein?

gparted_Screenshot_20240810_104951.png
 
Die Aufteilung zeigt für mich an, das dort legacy-Bios läuft.
2 primäre Partitionen, der Rest in einer Erweiterten Partition.
 

susejunky

Moderator
Teammitglied
Hallo @Pirx ,

Der YaST in der 15.6 hat unter 'Bootloader-Optionen, [X] Fremdes OS testen' das 15.5-System erkannt. Ich habe die "Zeitüberschreitung in Sekunden" ein wenig heruntergesetzt und den Grub2 neu schreiben lassen. Beim folgenden Neustart wurde die 15.5 auch korrekt angeboten. Der Versuch, die 15.5 dann auch hochzufahren, endete aber in der Meldung:
nahezu alle Fälle, in denen ich beim Systemstart im "emergency mode" gelandet bin, wurden durch einen fehlerhaften Eintrag in der Datei /etc/fstab verursacht.

Das Bild in Deinem Beitrag #3 zeigt nur eine SWAP-Partition, daher meine Vermutung:

Du hast bei der Installation von openSUSE Leap 15.6 die vorhandene SWAP-Partition neu formatiert (wodurch sich deren UUID geändert hat). Dein openSUSE Leap 15.5 System verwendet jedoch noch die "alte" UUID und diese kann beim Starten (von 15.5) nicht gefunden werden.

Viele Grüße

susejunky
 
Hallo @Pirx ,


nahezu alle Fälle, in denen ich beim Systemstart im "emergency mode" gelandet bin, wurden durch einen fehlerhaften Eintrag in der Datei /etc/fstab verursacht.

Das Bild in Deinem Beitrag #3 zeigt nur eine SWAP-Partition, daher meine Vermutung:

Du hast bei der Installation von openSUSE Leap 15.6 die vorhandene SWAP-Partition neu formatiert (wodurch sich deren UUID geändert hat). Dein openSUSE Leap 15.5 System verwendet jedoch noch die "alte" UUID und diese kann beim Starten (von 15.5) nicht gefunden werden.

Viele Grüße

susejunky
Oja, das kann wirklich die entscheidende heiße Spur sein.

Aber da kommt natürlich gleich die Frage auf: Wie kann ich diese Inkonsistenz beseitigen?
 
Wie wäre folgendes:
  1. Ich könnte aus der /etc/fstab in der 15.6 die besagte UUID für swap ablesen,
  2. dann die /etc/fstab der 15.5 öffnen und
  3. die in Schritt 1 ermittelte UUID für die swap dort eintragen.
Macht das Sinn? Muss ich noch mehr beachten?
 

susejunky

Moderator
Teammitglied
Hallo @Pirx ,

Wie kann ich diese Inkonsistenz beseitigen?
Du startest Dein openSUSE Leap 15.6 System und ermittelst zunächst die aktuelle UUID Deiner SWAP-Partition (z.B. aus der Datei /etc/fstab oder mit sudo blkid).

Dann erstellst Du eine chroot-Umgebung mit Deinem openSUSE Leap 15.5:
Code:
su -
Kennwort für Benutzer "root":

mount /dev/sda6 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /run /mnt/run
mount -o bind /sys /mnt/sys

chroot /mnt

vi /etc/fstab

dracut -f

exit
(ACHTUNG! Prüfe, ob sda6 tatsächlich die "/"-Partition Deines openSUSE Leap 15.5 Systems ist, ggf. anpassen)

Mit vi (oder einem anderen Editor Deiner Wahl) änderst Du die UUID der SWAP-Partition und erstellst anschließend mit dracut -f eine neue initrd-Datei (Das ist zwingend notwendig, da in der initrd ebenfalls auf die SWAP-Partition verwiesen wird!). Dann verlässt Du die chroot-Umgebung mit exit und startest Dein System neu.

Viele Grüße

susejunky
 
Hallo susejunky

Danke für deine Tipps und deine konkreten Anweisungen. Zum Unterpunkt betreffend Anpassung der /etc/fstab unter der Leap 15.5 bin ich noch unsicher. Die /etc/fstab unter der Leap 15.5 hat, anders als ihr Gegenstück unter der 15.6, bisher deinen Eintrag betreffend swap. Im direkten Vergleich schaut es so aus:
Code:
pirx@fuji156:~> date
Sa 10. Aug 17:29:45 CEST 2024
pirx@fuji156:~>
pirx@fuji156:~> cat /etc/fstab
UUID=dd58797d-f952-4f3d-953b-1f51c10a9bd5  swap      swap  defaults      0  0
UUID=a8048ab5-6356-4509-aa5b-3c4fa63397ab  /         ext4  defaults      0  1
UUID=103f4bd8-25d6-4879-ad6f-cad378bcf376  /home     ext4  data=ordered  0  2
UUID=0ccb84a6-1990-4627-ab76-0f852820bf17  /data1    ext4  data=ordered  0  2
UUID=703e73b0-2ef5-46d1-8296-d90f572dba26  /data2    ext4  data=ordered  0  2
UUID=3d01a038-154d-4383-b335-435f4e98edb1  /home155  ext4  data=ordered  0  2
UUID=99ac963f-24d8-487c-9073-be41541ae48e  /155      ext4  data=ordered  0  2
pirx@fuji156:~>
pirx@fuji156:~> cat /155/etc/fstab
UUID=99ac963f-24d8-487c-9073-be41541ae48e  /         ext4  defaults      0  1
UUID=3d01a038-154d-4383-b335-435f4e98edb1  /home     ext4  data=ordered  0  2
UUID=0ccb84a6-1990-4627-ab76-0f852820bf17  /data1    ext4  data=ordered  0  2
UUID=703e73b0-2ef5-46d1-8296-d90f572dba26  /data2    ext4  data=ordered  0  2
pirx@fuji156:~>

Soll ich in die fstab der 15.5 einfach eine Kopie der kompletten ersten Zeile der fstab aus der 15.6 eintragen?

Und gleich noch eine (im gegenwärtigen Stadium hypothetische) Frage hinterher: Wenn ich die Installation der Leap 15.6 wiederholen würde, diesmal aber ohne Formatierung der swap, käme ich dann nicht auch wieder zu einer lauffähigen Leap 15.5?
 
Wenn ich die Installation der Leap 15.6 wiederholen würde,
dann änderst Du die Situation nicht, da die UUID neu vergeben wurde.

Wenn Du mit
[FAILED] Failed to start Load Kernel Modules.
den tatsächlichen Fehler (und nicht einen Folgefehler) gefunden hast, hat das nichts mit SWAP zu tun. Vielleicht solltest Du doch mehr von den Meldungen zeigen (die Zeile stammt nicht vom Kernel, sondern vermutlich von systemd, aber zu dessen Eingriffen in den Startvorgang kann ich nichts sagen).
 

susejunky

Moderator
Teammitglied
Hallo @Pirx ,

Die /etc/fstab unter der Leap 15.5 hat, anders als ihr Gegenstück unter der 15.6, bisher deinen Eintrag betreffend swap.
wie ich in meinem Beitrag #6 gesagt habe: Das mit der SWAP-Partition war eine Vermutung meinerseits.
Soll ich in die fstab der 15.5 einfach eine Kopie der kompletten ersten Zeile der fstab aus der 15.6 eintragen?
Wenn Dein openSUSE Leap 15.5 bereits vor der Installation von openSUSE Leap 15.6 mit dieser fstab-Datei:
Code:
pirx@fuji156:~> cat /155/etc/fstab
UUID=99ac963f-24d8-487c-9073-be41541ae48e  /         ext4  defaults      0  1
UUID=3d01a038-154d-4383-b335-435f4e98edb1  /home     ext4  data=ordered  0  2
UUID=0ccb84a6-1990-4627-ab76-0f852820bf17  /data1    ext4  data=ordered  0  2
UUID=703e73b0-2ef5-46d1-8296-d90f572dba26  /data2    ext4  data=ordered  0  2
pirx@fuji156:~>
voll funktionstüchtig war, dann sollte es auch weiterhin mit dieser fstab-Datei start-/lauffähig sein.

Wenn der Start von openSUSE Leap 15.5 im "emergency mode" endet
Code:
You are in emergeny mode. After logging in, type "journalctl -xb"
to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Administratorpasswort für Wartungszwecke eingeben
(oder drücken Sie Strg+D, um fortzufahren
solltest Du Dich mit Deinem root-Kennwort (für 15.5) anmelden und mit journalctl -xb den Inhalt der Logdatei anzeigen können.

Viele Grüße

susejunky
 
Es hat geklappt!

Es hat genügt, die Datenzeile für die swap-Partition aus der fstab der 15.6 hinüberzukopieren in die fstab der 15.5. Irgendwelche weitere Maßnahmen betreffend Erstellung einer initrd waren überflüssig.

Josef hat natürlich recht: Wird einer swap-Partition ein UUID zugewiesen, dann ist dies ein nichtumkehrbarer Vorgang. Meine Idee, die Installation der 15.6 zu wiederholen, war Quatsch.

Danke an alle, die sich mit mir zusammen den Kopf zerbrochen haben.

Pirx
 

susejunky

Moderator
Teammitglied
Hallo @Pirx ,

Es hat genügt, die Datenzeile für die swap-Partition aus der fstab der 15.6 hinüberzukopieren in die fstab der 15.5. Irgendwelche weitere Maßnahmen betreffend Erstellung einer initrd waren überflüssig.

Schön, dass Du nun beide Systeme (15.5 und 15.6) nutzen kannst.

Allerdings ist es schon seltsam, dass Dein openSUSE Leap 15.5 System früher (d.h. bevor Du openSUSE Leap 15.6 zusätzlich installiert hast) problemlos ohne diese Zeile funktioniert hat. Hast Du eine Erklärung dafür?

Viele Grüße

susejunky
 
"Erklärung" wäre zu hoch gegriffen. Ich kann nur beschreiben, was ich gemacht habe und welcher Effekt dadurch erzielt wurde:
  • Befund 1: Nach Installation einer neuen Systemversion (15.6) kam die alte Systemversion (15.5) nicht mehr in die Gänge, obwohl sie selbst keine Veränderung erlebt hatte.
  • Befund 2: Nach Anpassung einer bestimmten Systemdatei (/etc/fstab) in der 15.5 nach dem Vorbild ihres Gegenstücks in der 15.6 lief alles wieder rund.
  • Die 15.5 und die 15.6 laufen in jeweils ihrer eigenen Konfiguration völlig unabhängig voneinander. Wechselwirken können sie nur im Zugriff auf das partionierte Dateisystem auf der Festplatte.
  • Vermutung: Die 15.5 hat nach dem swap gesucht, ihn aber nicht gefunden, weil letzterer in der Zwischenzeit einen UUID erhalten hatte, von der die 15.5 nichts wusste. M.a.W. die Suche nach dem swap scheiterte, weil plötzlich ein UUID da war, den es früher nicht gab.
So lauten meine - zugegeben nicht sehr tiefgründigen - Erklärungsversuche.

Grüße
Pirx
 
Mir ist noch etwas eingefallen:

Ich habe vor einigen Tagen einen "Trockenlauf" der Installation von Debian 12 Bookworm gemacht - also bis zu dem Punkt, wo etwas auf die Platte geschrieben werden soll. Eigentlich kann dabei nichts Schlimmes passiert sein.

Weiterhin kann es sein, dass ich zwischen besagtem Trockenlauf und den gestern aufkommenden Problemen die Leap 15.5 auf jenem PC, um den es hier geht, gar nicht mehr benutzt habe. Wir haben zwei Computer im Haus, beide meist mit denselben Leap-Installationen. Und wo ich mich als nächstes hinsetze, weiß ich kurz vorher oft auch noch nicht.

Spekulation, Spekulation, Spekulation...
 
Code:
pirx@fuji155:~> date
So 11. Aug 09:24:47 CEST 2024
pirx@fuji155:~>
pirx@fuji155:~> uname -a
Linux fuji155 5.14.21-150500.55.68-default #1 SMP PREEMPT_DYNAMIC Wed Jun 5 21:39:05 UTC 2024 (40e256a) x86_64 x86_64 x86_64 GNU/Linux
pirxr@fuji155:~>
pirx@fuji155:~> l /proc/cmdline
-r--r--r-- 1 root root 0 11. Aug 2024  /proc/cmdline
pirx@fuji155:~> 
pirx@fuji155:~> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.68-default root=UUID=99ac963f-24d8-487c-9073-be41541ae48e splash=silent preempt=full mitigations=auto quiet security=apparmor
pirx@fuji155:~>

Das ist jetzt ein wenig mehr Information, als Josef eigentlich haben wollte. Aber ich wollte auch selbst verstehen, was wie womit zusammenhängt.

Einen schönen Sommertag
Pirx
 
In der Kernel-Befehlszeile wird weder eine SWAP-Partition noch noresume angegeben. Wenn wirklich nichts bei 15.5 geändert wurde, fällt mir nur eine Möglichkeit ein: In der initrd wird die SWAP-Partition angesprochen. Exisitiert die dort genannte UUID, ist alles in Ordnung. Exisitiert sie nicht, aber in /etc/fstab ist eine existierende UUID eingetragen, ist auch alles in Ordnung. Ansonsten gibt es ein Problem.

Um festzustellen, ob dieses Konstrukt stimmt, müßte ein openSUSE-Kundiger die initrd analysieren. Vielleicht reicht auch der Versuch, die SWAP-Partition aus /etc/fstab zu entfernen und dafür in der Kernel-Befehlszeile noresume zu verwenden. Oder es wird nach der Entfernung aus /etc/fstab eine neue initrd erstellt, und die Kernel-Befehlszeile bleibt unverändert. Wenn das System startet, ist das für mich ein starkes Indiz für die genannte Möglichkeit.
 
Oben