Ich habe heute den gleichen Fehler auf einem Laptop mit Ubuntu 15.10 gesehen, der immer auf dem neuesten Stand war, aber erst nach einem Monat neu gestartet wurde, als ich einen aktuellen Kernel testen wollte (dh es gab möglicherweise eine kürzlich erfolgte Änderung).
Jedenfalls stellte ich fest, dass in meinem Fall die Ursache tatsächlich eine "fehlende" Swap-Partition war, die auf einen Setup-Fehler zurückzuführen war, als ich dem obigen Tutorial folgte. Wenn dies der Fall ist und / oder Sie tatsächlich verwenden lvm
, können Sie möglicherweise Schritt 2 überspringen. Natürlich wird möglicherweise auch die obige Fehlermeldung angezeigt, falls Ihre Systempartition (oder eine sekundäre Datenpartition) beschädigt wurde oder nicht gefunden werden kann (siehe Schritt 3).
Schritt 1: Hängen Sie Ihr System ein und starten Sie die Partitionen gemäß dem oben beschriebenen Lernprogramm
Lassen Sie uns sagen , dass Ihre (ext2) Boot - Partition / dev / sdX1, Ihre (verschlüsselt) Swap - Partition / dev / sdX2, Ihre (verschlüsselten) Datenpartition / dev / sdX3 und Sie haben entschlüsselt erfolgreich letztere mit cryptsetup luksOpen /dev/sdX3 data
, gefolgt von Montage es: mkdir /tmp/data; mount /dev/mapper/data /tmp/data
.
Beachten Sie die Bind-Mounts im Lernprogramm und stellen Sie sicher, dass Sie / dev / sdX1 mounten, damit Sie über das Verzeichnis / boot Ihrer Systempartition darauf zugreifen können (dies ist für die Ausführung von entscheidender Bedeutung update-initramfs
).
Im Folgenden wird davon ausgegangen, dass Sie erfolgreich ausgeführt wurden chroot /tmp/data/@ubuntu1510
(oder wie auch immer Ihre gemountete Systempartition heißt).
Schritt 2: Beseitigen Sie die obige Fehlermeldung
Ich verwende btrfs (wie Sie vielleicht anhand des erwähnten Subvolume-Namens erraten haben), so dass lvmetad leicht wie folgt deaktiviert werden kann, ohne die Funktionalität zu verlieren:
- Bearbeiten Sie die Datei /etc/lvm/lvm.conf und wechseln Sie
use_lvmetad=1
zuuse_lvmetad=0
- ausführen
update-initramfs -k $(uname -r) -u ; sync
Nun, Sie könnten neu starten und die Fehlermeldung weg sein sollte. In meinem Fall hat mich die nächste Fehlermeldung [1] jedoch auf das oben erwähnte zugrunde liegende Problem aufmerksam gemacht.
Schritt 3: Stellen Sie sicher, dass / etc / crypttab auf die richtigen, unbeschädigten Partitionen verweist
Führen Sie zunächst aus, sfdisk --list /dev/sdX
und überprüfen Sie, ob Ihre verschlüsselte Swap-Partition (in meinem Fall / dev / sdX2) tatsächlich nicht als (normale) Swap-Partition angezeigt wird . Wenn dies der Fall ist (wie in meinem Fall), bedeutet dies, dass beim Booten, z. B. mit einer Rettungsdiskette, wahrscheinlich diese verfügbare Swap-Partition verwendet wird, wodurch Ihre Cryptsetup-bezogenen Metadaten (Schlüsselphrase und UUID) überschrieben werden.
Schauen Sie sich als Nächstes / dev / disk / by-uuid an und vergleichen Sie die entsprechenden UUIDs Ihrer verschlüsselten Partitionen mit denen in / etc / crypttab. Meine Vermutung an dieser Stelle: In Ihrem Fall gibt es eine Nichtübereinstimmung.
Wenn die dedizierte verschlüsselte Swap-Partition unter / dev / disk / by-uuid nicht zu finden ist, wird sie derzeit von Ihrem Rettungssystem verwendet. In diesem Fall gehen Sie wie folgt vor:
- Stellen Sie sicher, dass Sie die Partition nicht mehr verwenden:
swapoff -a
- Formatieren Sie es neu:
mkfs.ext2 /dev/sdX2
(Dies ist von entscheidender Bedeutung , insbesondere bei Verwendung von GPT-Partitionen [2], da hierdurch der zuvor erwähnte Fehler behoben wird. Die wahrscheinliche Ursache für die Anzeige der Partition als Typ "swap" in der sfdisk-Auflistung ist, dass Sie / ich es versehentlich verwendet haben mkswap /dev/sdX2
beim Einrichten der Partition am Anfang.)
- Folgen Sie dem Tutorial, um die Partition zu verschlüsseln und eine Passphrase festzulegen. Öffnen Sie es anschließend mit cryptsetup und formatieren Sie die jetzt entschlüsselte Partition neu (mit etwas Ähnlichem
mkswap /dev/mapper/swap
).
- Stellen Sie sicher, dass
sfdisk --list /dev/sdX
die Swap-Partition nicht als solche identifiziert wird (wiederholen Sie in diesem Fall die letzten Schritte).
Überprüfen Sie nun erneut, ob die in / etc / crypttab aufgelisteten UUIDs in der Zeile stehen, die Sie unter / dev / disk / by-uuid für Ihre jeweiligen verschlüsselten Partitionen sehen.
Um die Änderungen dauerhaft zu machen, müssen Sie update-initramfs
wie oben gezeigt vorgehen.
Wenn Sie zufrieden sind, stellen Sie sicher, dass alles auf die Festplatte geschrieben ist, und starten Sie das System neu (Sie müssen nicht alles manuell aushängen). Danach sollte Ihr Problem behoben sein.
[1] Vielleicht habe ich beim ersten Mal nicht darauf geachtet, oder die erste Fehlermeldung hat die zweite "maskiert". dh erst nach dem Neustart (mit use_lvmetad=0
) wurde mir angezeigt, dass " alle physischen Volumes gelesen werden. Dies kann eine Weile dauern ... " (mehrmals wiederholt), gefolgt von " ALERT! / dev / disk / by-uuid / .. existiert nicht. " (Es ist zu beachten, dass update-initramfs
auch über eine fehlende Partition geklagt wird.)
[2] weil ihr Typ von der Analyse ihres Inhalts abgezogen und letztendlich nicht durch ein Flag / Byte angegeben wird (daher gibt es keine einfache Möglichkeit, z. B. den GPT-Dateisystemtyp mit zu ändern [g]parted
.)