it-swarm.com.de

"Lvmetad ist noch nicht aktiv und verwendet die direkte Aktivierung während sysinit" beim Booten?

Vor einiger Zeit habe ich Ubuntu 16.04 auf meinem PC installiert. Alles ist gut gelaufen und bisher keine Probleme. Als das erste Kernel-Update herauskam, konnte ich es nicht starten und bekam den folgenden Fehler:

Lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg

Als ich den alten Kernel aus dem Menü GRUB auswählte, war es in Ordnung und es gab keine Probleme. Danach kam ein weiteres Kernel-Update heraus und auch das hat nicht geklappt. Grundsätzlich habe ich nach dem Anklicken der neueren Kernelversion den Fehler bekommen und wurde auf dem Bildschirm immer wieder wiederholt (ohne Ende, zumindest nicht getestet).

Ich habe folgendes ohne Glück versucht:

Beides hat nicht funktioniert. Ich habe meine Festplatte verschlüsselt, da dies während der Installation eine Option war, und ich dachte, warum nicht? Ich denke, dass damit etwas los ist, obwohl es eher ein Bauchgefühl als ein harter Beweis ist. Ich habe gesucht, ob es möglich ist, die Verschlüsselung zu deaktivieren, und es war eine ziemlich mühsame Arbeit, also habe ich aufgehört, danach zu suchen, aber wenn das die Lösung zu sein scheint, kann ich es trotzdem versuchen.

Die installierte Kernel-Version war also 4.4.0-21-generic (wie in GRUB angezeigt). Funktioniert gut, keine Probleme. Danach waren die installierten Kernel 4.4.0-22-generic, 4.4.0-24-generic und 4.4.0-28-generic (wie in GRUB zu sehen). Was alle drei nicht funktionieren und genau den gleichen vorherigen Fehler geben.

Warum erhalte ich den Fehler und wie behebe ich ihn?

2
user3892683

Ich hatte die gleichen Fehlermeldungen, nachdem ich ein Release-Upgrade von Ubuntu 14.04 LTS auf 16.04 LTS in einer Chroot (Chroot wie in dieser deutsche Artikel ) von einem Live-System durchgeführt hatte.

Der Fehler trat vor der Passwortabfrage auf. Da sich die LVM-Datenträgergruppe normalerweise innerhalb des verschlüsselten Datenträgers befindet, muss es sich um ein Problem mit der Konfiguration von dm_crypt/LUKS handeln.

Ich habe eine Lösung gefunden hier und werde es unten erklären.


In meinem Fall unterschied sich der Name des Mapper des verschlüsselten Volumes von dem in/etc/crypttab angegebenen Namen.

Ich habe den Namen des luks mapper aus der Ausgabe von ls -l /dev/mapper ausgewählt , nachdem ich das verschlüsselte Gerät mit dem grafischen Dateimanager geöffnet habe . In meinem Fall war die Ausgabe:

control
luks-87fc4c8e-017b-8482-cd09-7332fe351628
vgubuntu-root
vgubuntu-swap

Dann habe ich als root meine/etc/crypttab geändert (bitte den Zeilenanfang beachten) von:

sda5_crypt UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

zu:

luks-87fc4c8e-017b-8482-cd09-7332fe351628 UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

Endlich habe ich meine initramfs aktualisiert:

update-initramfs -u -k all

Es war ein bisschen verwirrend, dass diese beiden Namen unterschiedlich waren. Man würde annehmen, dass der Name des Mapper beim Erstellen aus dem Crypttab stammt. Wie auch immer, es hat funktioniert.

Ich habe das ganze Zeug in einer Chroot gemacht und ein Live-System betrieben. Es funktioniert möglicherweise auch über die Busybox-Shell, in die Sie nach dem Booten des Systems fallen, aber ich habe es nicht versucht.

2
casi