Estoy tratando de configurar un volumen cifrado siguiendo esta guía
Todo está configurado, pero el montaje del volumen cifrado falla en el momento del arranque con el error:
fsck.ext4: No existe tal archivo o directorio al intentar abrir / dev / mapper / safe_vault ¿Dispositivo posiblemente inexistente?
Esta es mi configuración:
criptab
$ sudo cat /etc/crypttab
safe_vault /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b none luks
NOTA:
El uuidviene de:
$ 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
Qué he hecho...
Así que fui al sitio web del devorador y en las Preguntas frecuentes sobre problemas comunes dicen:
Comprueba que tienes el mapeador de dispositivos y el objetivo de la cripta en tu núcleo. La salida de los "objetivos dmsetup" debería enumerar un objetivo "cripta". Si no está allí o el comando falla, agregue el mapeador de dispositivos y crypt-target al núcleo.
Así que lo hice, resulta que no tengo un cryptobjetivo:
$ sudo dmsetup targets
striped v1.4.1
linear v1.1.1
error v1.0.1
El problema es que no sé cómo agregar ese objetivo.
Creo que esto (no tener el cryptobjetivo) puede hacer que la crypttabconfiguración se ignore en el momento del arranque y, por lo tanto, intentar montar la entrada fstabfalla porque cryptsetupno ha asignado mi volumen cifrado /dev/mapper/safe_vault.
NOTA:
El volumen cifrado se puede mapear, montar y escribir con éxito manualmente:
$ 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
Así es como se ve después de mapearlo y montarlo:
$ 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
ACTUALIZAR
- Resulta que tengo el
cryptobjetivo, pero para que se muestredmsetup targetstenía que primerocryptsetup luksOpen <my-device> - Intenté usar
UUIDs en su lugar de acuerdo con la respuesta de @Mikhail Morfikov, pero todavía falla en el momento del arranque.
Todavía creo que el problema es que, de alguna manera, el volumen cifrado no se asigna (se abre con cryptsetup luksOpen) en el momento del arranque, por lo que no /dev/mapper/<safe_vault or UUID>existe, por lo que falla el intento de montarlo (fstab).
ACTUALIZACIÓN 2
Resulta que no tenía los scripts necesarios para montar en el momento del arranque. Vea la nota en la respuesta de @ MikhailMorfikov.
fuente

luksOpen? Esperaría que si no estuviera allí, luksOpen también fallaría.sudo cryptsetup luksOpenque aparecen dos nuevos objetivos parasudo dmsetup targets:errorycrypt. Supongo que necesito cambiar la pregunta entonces .../dev/mapper/<my-logical-volume>-safe_vaultes un volumen lógico creado con LVM y/dev/mapper/safe_vaultes el dispositivo al que se asigna haciendocryptsetup luksOpen /dev/mapper/<my-logical-volume>-safe_vault. ¿Sabes sicrypttabfunciona con volúmenes LVM?/boot). Todo montado en el arranque sin problema. ¿Estás seguro de que actualizasteinitramfsdespués de editar/etc/crypttab? ¿Puedes mostrar la salida delsblk -o name,uuid,mountpointcuando todo está montado y funciona como debería?Respuestas:
Tienes que prestar atención a los UUID. Por ejemplo, esta es mi configuración:
Tengo una partición encriptada (sda2) con 4 volúmenes (LVM). Lo que necesito es configurar dos UUID en los archivos correctos. El UUID sda2 va a
/etc/crypttaby el UUID de volumen (por ejemplo debian_crypt-root) va a/etc/fstab.Entonces, sería:
Después de cambiar el
/etc/crypttabarchivo, debe reconstruir initramfs:NOTA
El paquete
cryptsetupdebe instalarse porque tiene scripts de inicio que proporcionan soporte para el montaje automático de volúmenes cifrados en el arranque.¿Por qué molestarse en mencionar esto? Bueno, si la configuración LVM durante la instalación de Debian Wheezy instala los paquetes cryptsetup-bin ,
libcryptsetup4ylvm2aunque nocryptsetup, por lo tanto usted tiene las herramientas para dispositivos de configuración LVM y LUKS pero no los scripts necesarios para montar dispositivos LUKS en el arranque. Esos vienen en el paquete cryptsetup .fuente
UUIDpero me sale el mismo error. Actualizaré la pregunta con detalles.Parece que la respuesta de @Mikhail Morfikov cubre el montaje durante la etapa initramfs . Una alternativa (si no es el sistema de archivos raíz) es descifrar y montar la partición automáticamente a través de systemd , después de cargar el kernel de linuz. Por supuesto, esto solo es posible si está ejecutando systemd . Explicaré el método aquí:
La
/etc/crypttabentrada:Aquí
noautohay una instrucción para no intentar descifrar el disco durante la etapa initramfs .Arriba,
e412-blahblahestá el UUID de la partición que contiene el sistema luks, en mi caso una partición/dev/sdb2:Durante el inicio del kernel de linuz, systemd leerá el
/etc/crypttabarchivo y creará un archivo de servicio en tiempo de ejecución/run/systemd/generator/[email protected]. Sin embargo, ese servicio no se ejecuta automáticamente. Puedes ejecutarlo manualmentepero para descifrarlo y luego montarlo durante el inicio,
/etc/fstabpuede requerirlo de la siguiente manera:Aquí
x-systemd.automounthay una instrucción para systemd para montar/media/crypt-data, y[email protected]es una instrucción para systemd quecrypt2se requiere descifrar antes de que sea posible.En systemd , en realidad no montará el directorio hasta la primera vez que se acceda a él, por ejemplo
ls /media/crypt-data, se montará justo a tiempo y aparecerá a partir de entonces/proc/mounts.Relacionado
Puede preguntar "* ¿por qué tener un disco de datos cifrados con la clave en el sistema de archivos raíz?". Esto se debe a que el sistema de archivos raíz también está encriptado, por lo que la clave está segura. El sistema de archivos raíz se descifra durante la etapa de arranque initramfs , a la respuesta de Mikhail. Tengo otra entrada en el
/etc/crypttabarchivo para eso:y describo la configuración de eso y un USB de arranque aquí
fuente