Carambakaracho
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Hallo zusammen, ich hab seit einigen Wochen Probleme beim booten meines verschlüsselten Systems. Wenn ich das System boote kommt der Vendor-Splash screen, aber keine Passwortabfrage mehr. Nach strg-alt-entf wird das grub boot Menü gezeigt, und wenn ich dann Ubuntu starte kommen folgende Fehlermeldungen:
[ 0.573403] Initramfs unpacking failed: Decoding failed
Volume group "vgubuntu" not found
Cannot process volume group vgubuntu
Dann kommt allerdings die Passwortabfrage, und das System wird entschlüsselt und ich bin eingeloggt. Das ist etwas suboptimal und ausserdem werden einige Systemeinstellungen nicht sauber initialisiert - z.B. die Soundeinstellungen. Das System ist nicht Standard verschlüsselt, sondern im großen und ganzen nach der Anleitung aus dem Wiki System verschlüsseln, bzw. dem Ubuntu.com ManualFullSystemEncryption Aufgetreten ist es mit einem Kernelupdate im November, leider hab ich mir das nicht gemerkt mit welchem Kernel, weil ein booten mit dem vorherigen Kernel das Problem nicht behoben hat und ich zu der Zeit recht viel um die Ohren hatte. Folgende Versuche habe ich schon unternommen:
Ich wäre dankbar über jede Hilfe, um zu finden was ich übersehe.
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
Schuss ins Blaue, ist Dein "/boot" vielleicht voll und deshalb nur ein kaputtes "initrd..." vorhanden oder das Dateisystem da kaputt? Schau mal genauer in das angeblich kaputte "initrd.." auf /boot, z.B. per "lsinitramfs /boot/initrd...." Befehl und dann, falls das lesbar ist kannst Du dort nach den Einträgen für "crypto" und dem Zeugs schauen. Eigentlich geht bei einem kaputten initrd.... nix mehr, d.h. auch das was Du beschreibst funktioniert dann nicht. Und zum Abschluss, ändere die grub-Bootmenü Einstellungen damit Du immer das boot-Menü siehst und Du zumindest da mal händisch die Bootoptionen für den Kernel ändern kannst (meist auf "noquiet nosplash noplymouth") um vom Bootvorgang etwas zu sehen (und vielleicht zu erahnen wo es nicht funktioniert).
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Hi nochmal, sorry tagsüber ist das hoch und runter fahren immer etwas schwierig... Dank deines letzten Tipps bin ich einen Schritt weiter. Als ich noquiet nosplash noplymouth in die grub Optionen einfügen wollte ist mir aufgefallen, dass ich den rootdelay rausgenommen habe. Jetzt ist zumindest das Initramfs unpacking failed: Decoding failed nicht mehr da, obwohl das auch ohne den rootdelay Parameter mal funktioniert hat. Jetzt ist der Bootvorgang auch wieder so aufschlussreich, wie ich das von vor 10 Jahre kannte 😛 und das sind die letzten Meldungen vor der Codeabfrage
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
Volume group "vgubuntu" not found
Cannot process volume group vgubuntu
Please unlock disk lukslvm: Ausserdem:
/boot sieht gut aus und ist zu 30% belegt lsinitramfs /boot/initrd.img-5.4.0-58-generic ist definitv lesbar, ich denke auch nicht, dass der Fehler da liegt, nachdem durch den rootdelay die initramfs Fehlermeldung nicht mehr angezeigt wird Die Installtion der Pakete sieht auch gut aus:
dpkg -l cryptsetup cryptsetup-initramfs lvm2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================-==================-============-===============================================
ii cryptsetup 2:2.2.2-3ubuntu2.3 amd64 disk encryption support - startup scripts
ii cryptsetup-initramfs 2:2.2.2-3ubuntu2.3 all disk encryption support - initramfs integration
ii lvm2 2.03.07-1ubuntu1 amd64 Linux Logical Volume Manager
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Was ich nicht ganz verstehe: Begin: Mounting root file system ... Könnte da ein Problem sein? root ist ja eigentlich eine verschlüsselte Partition in der volume group vgubuntu...
|
fleet_street
Top-Wikiautor
Anmeldungsdatum: 30. August 2016
Beiträge: 2130
Wohnort: Hunsrück
|
Carambakaracho schrieb: Das System ist nicht Standard verschlüsselt, sondern im großen und ganzen nach der Anleitung aus dem Wiki System verschlüsseln, bzw. dem Ubuntu.com ManualFullSystemEncryption
Im Großen und Ganzen schwammig. System verschlüsseln schreibt: … bleibt die Boot-Partition, … unverschlüsselt.
vs. Ubuntu.com ManualFullSystemEncryption schreibt: 3. encrypted Boot
Wo bist du welcher Anleitung gefolgt bzw. abgewichen? Carambakaracho schrieb: Könnte da ein Problem sein? root ist ja eigentlich eine verschlüsselte Partition in der volume group vgubuntu...
Das lässt sich sicher auch so konfigurieren, aber normalerweise wird das LVM in eine verschlüsselte Partition gepackt, weil das mehr Flexibilität ergibt.
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Boot ist nicht verschlüsselt, ich bin im recht nah an der Anleitung in unserem Wiki geblieben.
Carambakaracho schrieb: Könnte da ein Problem sein? root ist ja eigentlich eine verschlüsselte Partition in der volume group vgubuntu...
fleet_street schrieb:
Das lässt sich sicher auch so konfigurieren, aber normalerweise wird das LVM in eine verschlüsselte Partition gepackt, weil das mehr Flexibilität ergibt.
Das könnte meine Formulierung unter Umständen etwas unpräzise sein, ich hänge mal den output von lsblk -f an nvme0n1
├─nvme0n1p1 vfat D1BE-ABDB
├─nvme0n1p2 ext4 05731760-62a8-403b-bfd3-9e1af771936c
└─nvme0n1p3 crypto_LUKS 7f9f2398-20b1-430b-8b24-2b8231730e21
└─lukslvm LVM2_member UX487K-FJb3-114c-6M8J-HR4U-KXmk-weceyF
├─vgubuntu-swap swap 1577f571-ca85-4722-ba3c-ee553962c6e2
├─vgubuntu-root ext4 2a07d519-3a4c-4e12-9a0a-ebc319538de0
├─vgubuntu-tmp ext4 2e7e4ef5-5aa6-4cfe-ad3b-18253e61d489
├─vgubuntu-var ext4 68d69b79-be22-400c-9439-915c8895bf93
└─vgubuntu-home ext4 96d6c9d8-d0c4-4c99-9e05-ffde3e79dc84
|
klinge
Anmeldungsdatum: 17. Februar 2010
Beiträge: 407
Wohnort: Bern
|
auch von meiner Seite ein Schuss ins Blaue, aber ich meine mich zu erinnern, einen ähnlichen Fehler mal so oder ähnlich gelöst zu haben. schau dir mal /etc/crypttab an, das müsste m.E. so aussehen:
lukslvm UUID=7f9f2398-20b1-430b-8b24-2b8231730e21 (...) da beim Bootvorgang nach "vgubuntu" gesucht wird, steht dort vermutlich statt "lukslvm" eben "vgubuntu".
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Hi vielen Dank fuer den Tip, in der Tat hab ich mir die crypttab angeschaut, aber noch nicht gepostet. Ich hatte schon die Vermutung, dass die UUID falsch ist, aber das passt (zumindest ist es eins zu eins zu der Anleitung) cat /etc/crypttab
lukslvm UUID=7f9f2398-20b1-430b-8b24-2b8231730e21 none luks
|
klinge
Anmeldungsdatum: 17. Februar 2010
Beiträge: 407
Wohnort: Bern
|
dann noch mal ins Blaue: hast du grub aktualisiert?
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
Carambakaracho schrieb: Hi nochmal, sorry tagsüber ist das hoch und runter fahren immer etwas schwierig... Dank deines letzten Tipps bin ich einen Schritt weiter. Als ich noquiet nosplash noplymouth in die grub Optionen einfügen wollte ist mir aufgefallen, dass ich den rootdelay rausgenommen habe. Jetzt ist zumindest das Initramfs unpacking failed: Decoding failed nicht mehr da, obwohl das auch ohne den rootdelay Parameter mal funktioniert hat. Jetzt ist der Bootvorgang auch wieder so aufschlussreich, wie ich das von vor 10 Jahre kannte 😛 und das sind die letzten Meldungen vor der Codeabfrage
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
Volume group "vgubuntu" not found
Cannot process volume group vgubuntu
Please unlock disk lukslvm: Ausserdem:
/boot sieht gut aus und ist zu 30% belegt lsinitramfs /boot/initrd.img-5.4.0-58-generic ist definitv lesbar, ich denke auch nicht, dass der Fehler da liegt, nachdem durch den rootdelay die initramfs Fehlermeldung nicht mehr angezeigt wird Die Installtion der Pakete sieht auch gut aus:
dpkg -l cryptsetup cryptsetup-initramfs lvm2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================-==================-============-===============================================
ii cryptsetup 2:2.2.2-3ubuntu2.3 amd64 disk encryption support - startup scripts
ii cryptsetup-initramfs 2:2.2.2-3ubuntu2.3 all disk encryption support - initramfs integration
ii lvm2 2.03.07-1ubuntu1 amd64 Linux Logical Volume Manager
Deine Meldung oben sagt Dir doch was wohl verquer ist. /scripts/local-top und wenn Du in die initrd... reinschaust, dann gibt es da einige Scripte, die in der initrd.. unter /scripts/local-top/.. dafür sorgen wo und was zusätzlich bei Verschlüsselung gemacht wird und soweit ich weiß muss da auch der Name der verschlüsselten Teile für "root" etc. stehen, weil sonst der Boot-Vorgang ja gar nicht wissen kann wo sich auf verschlüsselten Datenträgern die notwendigen Teile verbergen. Würde mich nicht wundern, wenn dort "vgubuntu" stehen würde. Wie, warum etc. ist dann eine andere Frage, es würde aber erklären woher die Suche beim Boot danach kommt, denn irgendwo muss es ja stehen obwohl Du bei der Verschlüsselung andere Namen gewählt hast. Ohne jetzt explizit nachgesehen zu haben würde ich erstmal im /scripts/local-top/cryptroot nachsehen und dann woher so was (wenn es da ist) bei der Erstellung der initrd... gefüttert wird.
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Hi nochmal - vielen Dank schonmal für die Tips. Ich hab den Fehler zwar noch nicht gefunden, aber konnte immerhin die ein oder andere Wissenslücke schließen. Ich muss trotzdem noch das ein oder andere über die Details des Setups lernen, die ich teilweise nur in Bugreports finden konnte, z. B. hatte ich bisher die logical volumes vgubuntu-* noch via UUID in fstab gemounted, das ist wohl keine gute Idee, siehe 1573982, auch wenn ich im Moment noch keine Snapshot verwende. Ich hab mit den cryptroot und lvm2 Skripten in local-top vorsichtig experimentiert. , bisher aber noch keinen der von mir gewünschten Effekte erreichen können - was bisher im Grunde nur eine echo Befehl wäre um zu sehen ob ich an der richtigen Stelle bin [EDIT] Mit besseren log messages komme so langsam dahinter wie die boot Reihenfolge abläuft. Ich hab noch einige bugreports gefunden, die alle ein bisschen, aber nicht so richtig passen, und teste jetzt vgchange -ay in den beiden Skripten. An sich ist die volumegroup aktiv - warum der Fehler kommt ist mir etwas schleierhaft. Durch die reboots ist das ganze etwas Zeitaufwendig und ich hab dafür auch nur die Abendstunden - so zieht sich das etwas.
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
klinge schrieb: dann noch mal ins Blaue: hast du grub aktualisiert?11
Sorry für die späte Antwort auf die eigentlich einfache Frage - ich dachte zuerst ich kann das nicht mehr nachvollziehen, weil das Problem seit irgendwann Anfang November besteht. Ich hatte aber "Glück": Am 2.11 wurde grub aktualisiert:
grub-common:amd64 (2.04-1ubuntu26.4, 2.04-1ubuntu26.6)
Da aus irgendeinem, vermutlich damit zusammenhängenden Grund seit dem Mitte November keine boot.logs mehr geschrieben werden, hab ich tatsächlich noch einen log von vorher und nachher - siehe da, am 2.11 ist der boot.log noch okay, am 3.11 ist der Fehler an erster Stelle. Dementsprechend würde ich mal GRUB 2/Reparatur versuchen, wahrscheinlich eher gegen WE
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Carambakaracho schrieb:
ausserdem werden einige Systemeinstellungen nicht sauber initialisiert - z.B. die Soundeinstellungen.
Na, also das zumindest hab ich lösen können - bei dem Upgrade wurde anscheinend bei manchen Systemen die 64bit Version von systemd durch die 32 bit Version ersetzt, siehe z.B. hier bei ask Ubuntu, oder 1903273. Man, da ist aber mal ordentlich was schiefgegangen. Die Lösung für die nicht initialisierten Systemsettings ist also vom Problem des Entschlüsselns entkoppelt und lies sich lösen mit sudo apt install systemd:amd64 beim anschliessendem Aufräumen mit autoclean, autoremove, autopurge wurden noch einige 32 bit Systembibliotheken, u.a. libcryptsetup in der 32 bit version entfernt, was das Problem mit den nicht gefundenen volume groups allerdings noch nicht gelöst hat.
|
Carambakaracho
(Themenstarter)
Anmeldungsdatum: 11. Juli 2006
Beiträge: 223
Wohnort: de/bn
|
Nach noch etwas mehr Recherche hab ich herausgefunden, dass am ungefähr fraglichen Datum zwar auch Grub aktualisiert wurde - das eigentliche Problem aber ein aptdaemon Prozess war, der einige Tage später verschiedene Pakete durch 32bit Versionen ersetzt hat (siehe 1903273). Unter anderem wurde dabei Plymouth entfernt, was den Focus auf den boot vorgang lenkte, weil ich "scheinbar" kein Passwort mehr eingeben konnte und dann die volume group Fehlermeldung der erste greifbare Fehler schien. Also hab ich alle i386 Pakete gecheckt und entfernt, ebenso wie die komplette i386 Architektur in der Hoffnung, das so etwas so nicht wieder passiert, siehe askubuntu: | dpkg -l | grep i386 # check
sudo apt purge $(dpkg --get-selections | awk '$1 ~ /:i386$/ { print $1 }')
dpkg --remove-architecture i386
|
Im Grunde ist mein eigentliches Problem gelöst - das System funktioniert wieder wie gewünscht. Die volume group Fehlermeldung bleibt, und kommt aus /usr/share/initramfs-tools/scripts/local-top/lvm2 wenn die funktion lvchange_activate() aus dem /dev/mapper/* case aufgerufen wird: | lvm lvchange -aay -y --sysinit --ignoreskippedcluster vgubuntu/root
|
Falls da jmd. einen Tip hat wäre das noch interessant, sonst bleibt es so wie es ist (mit plymouth aktiviert sehe ich die Fehlermeldung nicht mehr 😉 )
|