Próbuję skonfigurować zaszyfrowany wolumin zgodnie z tym przewodnikiem
Wszystko jest skonfigurowane, ale instalacja zaszyfrowanego woluminu kończy się niepowodzeniem podczas uruchamiania z błędem:
fsck.ext4: Brak takiego pliku lub katalogu podczas próby otwarcia / dev / mapper / safe_vault Prawdopodobnie nieistniejące urządzenie?
To jest moja konfiguracja:
crypttab
$ sudo cat /etc/crypttab
safe_vault /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b none luks
UWAGA:
uuid
Pochodzi z:
$ sudo blkid /dev/mapper/<my_logical_group>-safe_vault
/dev/mapper/<my_logical_group>-safe_vault: UUID="d266ae14-955e-4ee4-9612-326dd09a463b" TYPE="crypto_LUKS"
fstab
$ sudo cat /etc/fstab | grep safe_vault
/dev/mapper/safe_vault /safe-vault ext4 defaults 0 2
Co ja zrobiłem...
Poszedłem więc na stronę dewelopera i w często zadawanych pytaniach często mówią:
Sprawdź, czy w jądrze znajduje się program mapujący urządzenia i cel szyfrowania. Dane wyjściowe „obiektów docelowych dmsetup” powinny zawierać listę obiektów docelowych „krypt”. Jeśli go nie ma lub polecenie nie powiedzie się, dodaj maper urządzeń i cel szyfrowania do jądra.
Tak zrobiłem, okazuje się, że nie mam crypt
celu:
$ sudo dmsetup targets
striped v1.4.1
linear v1.1.1
error v1.0.1
Problem polega na tym, że nie wiem, jak dodać taki cel.
Myślę, że to (nie posiadające crypt
celu) może powodować crypttab
ignorowanie konfiguracji podczas uruchamiania, a zatem próba zamontowania wpisu fstab
kończy się niepowodzeniem, ponieważ cryptsetup
nie zamapowałem mojego zaszyfrowanego woluminu /dev/mapper/safe_vault
.
UWAGA:
Zaszyfrowany wolumin można z powodzeniem ręcznie zmapować, zamontować i zapisać:
$ sudo cryptsetup luksOpen /dev/mapper/<my_logical_group>-safe_vault safe_vault
Enter passphrase for /dev/mapper/<my_logical_group>-safe_vault:
$ sudo mount /dev/mapper/safe_vault /safe_vault
Tak to wygląda po zmapowaniu i zamontowaniu:
$ sudo lsblk -o name,uuid,mountpoint
NAME UUID MOUNTPOINT
sda
├─sda1 28920b00-58d3-4941-889f-6249357c56ee
├─sda2
└─sda5 uhBLE7-Kcfe-RMi6-wrlX-xgVh-JfAc-PiXmBe
├─<my_logical_group>-root (dm-0) 1bed9027-3cf7-4f8d-abdb-28cf448fb426 /
├─<my_logical_group>-swap_1 (dm-1) a40c16c4-7d0c-46d7-afc8-99ab173c20bb [SWAP]
├─<my_logical_group>-home (dm-2) e458abb7-b263-452d-8670-814fa737f464 /home
├─<my_logical_group>-other (dm-3) 0a1eec42-6534-46e1-8eab-793d6f8e1003 /other
└─<my_logical_group>-safe_vault (dm-4) d266ae14-955e-4ee4-9612-326dd09a463b
└─safe_vault (dm-5) 9bbf9f47-8ad8-43d5-9c4c-dca033ba5925 /safe-vault
sr0
AKTUALIZACJA
- Okazuje się, że mam
crypt
cel, ale żeby się pokazaćdmsetup targets
, musiałem najpierwcryptsetup luksOpen <my-device>
- Próbowałem za pomocą
UUID
S zamiast według @Mikhail Morfikov za odpowiedź ale jeszcze nie w czasie startu systemu.
Nadal uważam, że problem polega na tym, że w jakiś sposób zaszyfrowany wolumin nie jest mapowany (otwierany cryptsetup luksOpen
) w czasie uruchamiania, więc nie /dev/mapper/<safe_vault or UUID>
istnieje, a następnie próba zamontowania go (fstab) kończy się niepowodzeniem.
AKTUALIZACJA 2
Okazuje się, że nie miałem niezbędnych skryptów do zamontowania w czasie rozruchu. Zobacz notatkę w odpowiedzi @ MikhailMorfikov.
źródło
luksOpen
? Spodziewałbym się, że gdyby go nie było, luksOpen też by zawiodł.sudo cryptsetup luksOpen
pojawieniu się dwóch nowych celów dlasudo dmsetup targets
:error
icrypt
. Chyba muszę zmienić to pytanie .../dev/mapper/<my-logical-volume>-safe_vault
jest logicznym woluminem utworzonym za pomocą LVM i/dev/mapper/safe_vault
jest urządzeniem, na które jest mapowanycryptsetup luksOpen /dev/mapper/<my-logical-volume>-safe_vault
. Czy wiesz, czycrypttab
działa z woluminami LVM?/boot
). Wszystko zamontowane przy rozruchu bez problemu. Czy jesteś pewien, że zaktualizowałeśinitramfs
po edycji/etc/crypttab
? Czy możesz pokazać,lsblk -o name,uuid,mountpoint
kiedy wszystko jest zamontowane i działa tak, jak powinno?Odpowiedzi:
Musisz zwrócić uwagę na UUID. Na przykład jest to moja konfiguracja:
Mam jedną zaszyfrowaną partycję (sda2) z 4 woluminami (LVM). Potrzebuję ustawić dwa identyfikatory UUID w odpowiednich plikach. Identyfikator UUID sda2 idzie do,
/etc/crypttab
a identyfikator UUID woluminu (na przykład debian_crypt-root)/etc/fstab
.Byłoby to:
Po zmianie
/etc/crypttab
pliku musisz odbudować initramfs:UWAGA
Pakiet
cryptsetup
musi zostać zainstalowany, ponieważ zawiera skrypty startowe, które zapewniają obsługę automatycznego montowania zaszyfrowanych woluminów podczas rozruchu.Po co zawracać sobie tym głowę? Cóż, jeśli konfiguracja LVM podczas instalacji Debiana wheezy instaluje pakiety cryptsetup-bin ,
libcryptsetup4
alvm2
jednak niecryptsetup
, więc masz narzędzia do konfiguracji urządzeń LVM i luks, ale nie skrypty niezbędne do zamontowania urządzeń LUKS w czasie startu. Są one dostarczane w pakiecie cryptsetup .źródło
UUID
ale pojawia się ten sam błąd. Zaktualizuję pytanie o szczegóły.Wydaje się, że @Mikhail Morfikov za odpowiedź obejmuje montaż podczas initramfs etapie. Alternatywą (jeśli nie jest to główny system plików) jest odszyfrowanie i zamontowanie partycji automatycznie przez systemd po załadowaniu jądra Linuz. Oczywiście jest to możliwe tylko wtedy, gdy używasz systemd . Wyjaśnię tę metodę tutaj:
/etc/crypttab
Wpis:Oto
noauto
instrukcja, aby nie próbować odszyfrować dysku podczas etapu initramfs .Powyżej
e412-blahblah
znajduje się identyfikator UUID partycji zawierającej system Luks, w moim przypadku partycja/dev/sdb2
:Podczas uruchamiania jądra Linuz systemd odczyta
/etc/crypttab
plik i utworzy plik usługi wykonawczej/run/systemd/generator/[email protected]
. Jednak usługa ta nie jest uruchamiana automatycznie. Możesz uruchomić go ręcznieale aby go odszyfrować, a następnie zamontować podczas uruchamiania,
/etc/fstab
może wymagać tego w następujący sposób:Oto
x-systemd.automount
instrukcja systemd do zamontowania/media/crypt-data
i[email protected]
instrukcja systemd, że odszyfrowaniecrypt2
jest wymagane, zanim będzie to możliwe.W systemd nie zainstaluje katalogu aż do pierwszego dostępu, np.
ls /media/crypt-data
Wtedy zamontuje się dokładnie w czasie i pojawi się później/proc/mounts
.Związane z
Możesz zapytać „* dlaczego masz zaszyfrowany dysk z kluczem w głównym systemie plików?”. Dzieje się tak, ponieważ główny system plików jest również szyfrowany, więc klucz jest bezpieczny. System plików root jest odszyfrowywany na etapie bootowania initramfs , odpowiedź la Mikhaila. W tym
/etc/crypttab
pliku mam inny wpis :i opiszę konfigurowania że i USB rozruchu tutaj
źródło