Ich habe ein verschlüsseltes Ubuntu 14.04 Desktop-Setup. Die verschlüsselte Root-Partition wird mit den Standardparametern des Ubuntu-Installationsprogramms erstellt (Auswahlmöglichkeiten „Datenträger löschen und Ubuntu installieren“ und „Neue Ubuntu-Installation verschlüsseln“). Dieser Teil funktioniert einwandfrei (er fragt beim Booten nach einem Passwort und öffnet die Root- und Swap-Partitionen).
Später habe ich ein zweites Laufwerk hinzugefügt, das separat mit einer Schlüsseldatei verschlüsselt war, die auf der Root-Partition gespeichert war. Die Absicht war, es automatisch zu öffnen, sobald die Root-Partition geöffnet wird. Zu diesem Zweck wurde das zweite Laufwerk zu crypttab (per UUID) und sein verschlüsseltes Dateisystem zu fstab (per Bezeichnung, Einhängepunkt /stg) hinzugefügt.
Beim Booten erhalte ich nach Eingabe des Hauptentschlüsselungskennworts Folgendes:Beim Mounten von /stg ist ein Fehler aufgetreten. Drücken Sie S, um das Mounten zu überspringen, oder M für die manuelle Wiederherstellung..
Das Seltsame ist, wenn ich drückeMund führen Sie einfach aus mount -a. Die Installation funktioniert einwandfrei. Ich sehe nichts Verdächtiges in /var/log/syslog.
Was ist da los? Was kann ich überprüfen, um das Problem zu diagnostizieren?
[UPD – einige Details hinzugefügt]Das Laufwerk sdbverfügt über eine MBR-Partitionstabelle mit einer Partition. Das verschlüsselte Dateisystem wurde mit den folgenden Befehlen initialisiert:
cryptsetup luksFormat /dev/sdb1 /root/stg.key
cryptsetup luksOpen /dev/sdb1 stg_crypt -d/root/stg.key
mkfs.ext4 /dev/mapper/stg_crypt -Lstg-tmp
/etc/crypttab(tatsächliche UUIDs der Kürze halber durch den Text „uuid-of-…“ ersetzt):
# this entry was created by Ubuntu installer
sda5_crypt UUID=uuid-of-sda5 none luks,discard
# this entry was added by me
stg_crypt UUID=uuid-of-sdb1 /root/stg.key luks,discard
/etc/fstab:
# these entries were created by Ubuntu installer
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
UUID=uuid-of-sda1 /boot ext2 defaults 0 2
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# this entry was added by me
LABEL=stg-tmp /stg ext4 errors=remount-ro 1 2
Antwort1
Lustigerweise behebt das Ersetzen der Bezeichnungsreferenz fstabdurch den Gerätepfad das Problem! D. h.: LABEL=stg-tmpgeändert in /dev/mapper/stg_crypt.
Ich habe auch die UUID-Referenz ausprobiert, sie hat nicht funktioniert. Offenbar funktionieren die LABEL- und UUID-Referenzen beim Booten also für physische Partitionen, aber nicht für verschlüsselte Partitionen. Sie funktionieren jedoch mount -afür alle Partitionen.
Dies ist als Lösung nicht sehr zufriedenstellend (es fehlt beispielsweise eine Erklärung), aber es löst das vorliegende Problem, also denke ich, dass es für den Moment ok ist.
Antwort2
Der erste Gedanke ist, dass das Intramfs die Schlüsseldatei NICHT sieht (normales Verhalten)
Einige Korrekturen umfassen:
Hinzufügen/Erstellen einer Fallback-Passphrase für /stg wie hier beschrieben
Fallback zu Luks hinzufügen (scrollen Sie nach unten zum Abschnitt „Fallback-Passphrase hinzufügen“)
dd hinzufügen if=/dev/usbkey bs=512 skip=4 count=8 | cryptsetup luksOpen /dev/md0 luksVolume --key-file=- && mount /dev/mapper/luksVolume /mnt/
bei der Erstellung oder mithilfe von cryptsetup-reencrypt (in den Repos, aber nicht standardmäßig installiert)