ubuntuusers.de

Hallo,

nach dem update auf den Kernel 5.3.0-40 startet mein mit LUKS verschlüsseltes System nicht mehr, was offensichtlich daran liegt, dass ich beim Start nicht mehr nach dem Entschlüsselungspasswort gefragt werde und der Startprozess einfach so durchrauschen will, um sich dann per Busybox zu beschweren, dass er das Root-Laufwerk nicht findet.

Ja, natürlich, würde mich stark wundern, wenn er es fände. Es ist ja verschlüsselt und kann auch nicht gefunden werden, wenn man mich vorher nicht mal nach dem Passwort fragt.

Was ist hier beim Aktualisieren daneben gegangen, und wie kann ich es reparieren?

VG ubuntuuser1311161408

ubuntuuser1311161408 schrieb:

Was ist hier beim Aktualisieren daneben gegangen

Wird dir niemand sagen können, ohne die Meldungen zu kennen...

und wie kann ich es reparieren?

Erster Anlaufpunkt wäre älteren Kernel ausprobieren.

Wenn das nicht geht:

• Livesystem starten

• LUKS-Partition aufschließen

• und einhängen

• per chroot ins installierte System

• nachsehen, ob die Systemaktualisierung vollständig ist oder Fehlermeldungen bei nochmaligem Aufruf kommen

tomtomtom schrieb:

ubuntuuser1311161408 schrieb:

Was ist hier beim Aktualisieren daneben gegangen

Wird dir niemand sagen können, ohne die Meldungen zu kennen...

...
Scanning vor Btrfs filesystems
Begin: Waiting for suspend/resume device ...Begin: Running scripts/local-block ... done.
done.
Begin: Waiting for root file system ... Begin: Running scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
-Boot args (cat /proc/cmdline)
 -Check rootdelay= (did the system wait long enough?)
-Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID= ... does not exist. Dropping to a shell!

Dabei ist UUID die ID des entschlüsselten root-Dateisystems.

cat /proc/cmdline ergibt:

BOOT_IMAGE=/vmlinuz-5.3.0-40-generic root=UUID=... ro rootflags=subvol=@ noplymouth

und wie kann ich es reparieren?

Erster Anlaufpunkt wäre älteren Kernel ausprobieren.

Gleiches Ergebnis, nur dass in den Meldungen statt 5.3.0-40 eben 5.3.0-26 steht.

Wenn das nicht geht:

• Livesystem starten

• LUKS-Partition aufschließen

• und einhängen

• per chroot ins installierte System

• nachsehen, ob die Systemaktualisierung vollständig ist oder Fehlermeldungen bei nochmaligem Aufruf kommen

Gemacht. Keine Fehlermeldungen. Hat mir sogar Firefox upgedatet. Sah alles unauffällig aus.

Gruß ubuntuuser1311161408

Stochern im Dunkeln:

• nochmal ins chroot

• sudo apt-get install --reinstall cryptsetup cryptsetup-bin

• rootdelay=5 als zusätzliche Kerneloption in /etc/default/grub (siehe Fehlermeldung "-Check rootdelay= "), danach

  sudo update-grub

• danach noch ein

  sudo mkinitramfs

sieht nach einem Bug aus https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1864897

Hallo,

dann sollte ich vielleicht auf Behebung des Bugs warten bevor ich cryptsetup von der livecd via chroot neu installieren? Interessant ist, dass man im bug report vom Ausweichkernel 5.3.0-29 spricht. Den habe ich nicht. Ich habe nur 26. Und der läuft auf den gleichen Fehler.

Gruß ubuntuuser1311161408

Im Übrigen startet meine livecd für Ubuntu 19.10 auch nur im safe graphics modus.

sdfg978 schrieb:

sieht nach einem Bug aus https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1864897

Toll, grummel! Da läuft alles scheinbar problemlos durch und beim nächsten Start ist das System lahm. Wäre das mein einziger und wichtiger Rechner hätte ich jetzt ein Riesenproblem. Wegen angeblicher Stabilität bin ich u.a. von Windows auf Linux gewechselt. Dass ich nach einem Update überhaupt nicht mehr starten konnte, habe ich glaube ich bei Windows noch nicht erlebt.

Hallo,

auf der Suche nach dem Problem, habe ich nach dem Start mit einer Live-CD und mounten des kaputten Systems in einer chroot-Umgabung testweise

sudo modprobe dm-crypt

eingegeben und bekam prompt die Fehlermeldung:

modprobe: FATAL: Module dm-crypt not found in directory lib/modules/5.3.0-18-generic.

Das wäre möglicherweise die Erklärung, weswegen die Entschlüsselung beim Booten nicht funktioniert.

Im Ordner /lib/modules sind Unterordner mit allerhand Kernelversionen, unter anderem die besagte 5.3.0-18-generic. Diese Version wird auch angegeben wenn ich uname -r eingebe. Nach grub-update wurden aber die beiden Versionen 5.3-0-42 und 40 in die grub.cfg geschrieben. Irgendwas scheint durcheinander. Wie kann ich das beheben? Am besten so, dass die neuen Versionen verwendet werden.

Müssen die zahlreichen Unterordner mit alten Kernelversionen in /lib/modules sein oder genügen nur die beiden letztverwendeten 42 und 40? Interessanterweise befindet sich dort noch ein Unterordner 5.3.0-45-generic.

Viele Grüße ubuntuuser1311161408

Hallo ubuntuuser1311161408,

Siehe dich mal im WIKI zu Systempflege um .......

Was verlangst du den wenn du eine Zwischenversion die nur ca. 9 Monate gepflegt wird installiert hast ?

Gruss Lidux

Schon gemacht, aber nicht daraus schlau geworden.

ubuntuuser1311161408 schrieb:

Schon gemacht, aber nicht daraus schlau geworden.

Dort steht nämlich nicht ansatzweise, warum das System meint einen Kernel zu verwenden (5.3.0-18) der auf der Boot-Partition gar nicht vorhanden und in grub.cfg auch nicht eingetragen ist. Wie kommt Ubuntu also darauf? Bei den beiden dort eingetragenen ist auch die dm-crypt vorhanden. Wie bringe ich das System dazu dort hinzuschauen?

Der Kernel 5.3.0-18 ist vom Livesystem. Der wird durch chroot ja nicht gewechselt, oder? Hilft dir das ein wenig auf die Sprünge?

PS:
ubuntuuser1311161408 schrieb:

… Interessant ist, dass man im bug report vom Ausweichkernel 5.3.0-29 spricht. …

Hast du versucht einen anderen Kernel per chroot zu installieren?

Nicht wirklich. Jetzt bin ich verwirrt. Ich dachte mit chroot kann ich vom live-system aus mich im Terminal quasi online im installierten System bewegen. Ja, dort habe ich auch per update und upgrade neue Kernels installiert, die nunmehr dort sind.

ubuntuuser1311161408 schrieb:

… Ich dachte mit chroot kann ich vom live-system aus mich im Terminal quasi online im installierten System bewegen.

Das schon, aber es steht nirgends, dass der dort installierte Kernel aktiv sei. Das ginge auch ein wenig schnell binnen nullkommanix den Kernel zu starten. Verwechselst du das mit einer virtuelle Maschine?

Ich bin bislang nicht auf die Idee gekommen in einer chroot-Umgebung uname auszuführen; immer zielorientiert das erledigt, was ich wollte. Aber eben habe ich es gemacht. Von Ubuntu 19.10 aus in 20.04 gechrootet und uname meldet mir nach meinem Verständnis korrekt, dass ein 5.3er Kernel aktiv ist und kein 5.4er aus 20.04.

Ja, dort habe ich auch per update und upgrade neue Kernels installiert, die nunmehr dort sind.

Und startet das System immer noch nicht? Auch keine Fehlermeldungen?