Pourquoi mon volume LVM chiffré (périphérique LUKS) ne monte pas au démarrage?

15

J'essaie de configurer un volume chiffré en suivant ce guide

Tout est configuré mais le montage du volume chiffré échoue au démarrage avec l'erreur:

fsck.ext4: Aucun fichier ou répertoire de ce type lors de la tentative d'ouverture de / dev / mapper / safe_vault Peut-être un périphérique inexistant?

Voici ma configuration:

crypttab

$ sudo cat /etc/crypttab
safe_vault  /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b  none    luks

REMARQUE:

Le uuidvient 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

Ce que j'ai fait...

Je suis donc allé sur le site Web du devoper et dans la FAQ sur les problèmes courants, ils disent:

Vérifiez que vous avez le mappeur de périphériques et la cible de cryptage dans votre noyau. La sortie des "cibles dmsetup" doit répertorier une cible "crypt". Si ce n'est pas le cas ou que la commande échoue, ajoutez un mappeur de périphérique et une cible de cryptage au noyau.

Alors je l'ai fait, il s'avère que je n'ai pas de cryptcible:

$ sudo dmsetup targets
striped          v1.4.1
linear           v1.1.1
error            v1.0.1

Le problème est que je ne sais pas comment ajouter une telle cible.

Je pense que cela (ne pas avoir la cryptcible) peut provoquer l'ignorance de la crypttabconfiguration au démarrage et donc essayer de monter l'entrée dans fstabéchoue car cryptsetupn'a pas mappé mon volume crypté /dev/mapper/safe_vault.

REMARQUE:

Le volume chiffré peut être correctement mappé, monté et écrit manuellement:

$ 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

Voici à quoi il ressemble après le mappage et le montage:

$ 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

MISE À JOUR

  • Il s’avère que j’ai la cryptcible mais pour qu’elle apparaisse, dmsetup targetsj’ai dûcryptsetup luksOpen <my-device>
  • J'ai essayé d'utiliser UUIDs à la place selon la réponse de @Mikhail Morfikov, mais il échoue toujours au démarrage.

Je pense toujours que le problème est que, d'une manière ou d'une autre, le volume chiffré n'est pas mappé (ouvert avec cryptsetup luksOpen) au démarrage, il n'existe donc pas /dev/mapper/<safe_vault or UUID>, puis essayer de le monter (fstab) échoue.

MISE À JOUR 2

Il s'avère que je n'avais pas les scripts nécessaires à monter au démarrage. Voir la note dans la réponse de @ MikhailMorfikov.

lvm cryptsetup pgpb.padilla
la source
1
La cible de cryptage apparaît-elle après que vous l'ayez fait manuellement luksOpen? Je m'attendrais à ce que s'il n'était pas là, luksOpen échouerait aussi.
un CVn
Ok, après que sudo cryptsetup luksOpendeux nouvelles cibles apparaissent pour sudo dmsetup targets: erroret crypt. Je suppose que je dois changer la question alors ...
pgpb.padilla
Est-ce une partition ou un conteneur de fichiers?
Mikhail Morfikov
/dev/mapper/<my-logical-volume>-safe_vaultest un volume logique créé avec LVM et /dev/mapper/safe_vaultest le périphérique auquel il est mappé en faisant cryptsetup luksOpen /dev/mapper/<my-logical-volume>-safe_vault. Savez-vous si cela crypttabfonctionne avec des volumes LVM?
pgpb.padilla
J'ai LVM à l'intérieur d'une partition Luks, en fait j'ai mon disque entier de 1,5 To crypté (sauf /boot). Le tout monté au démarrage sans problème. Êtes-vous sûr d'avoir mis initramfsà jour après la modification /etc/crypttab? Pouvez-vous montrer la sortie lsblk -o name,uuid,mountpointlorsque tout est monté et fonctionne comme il se doit?
Mikhail Morfikov

Réponses:

16

Vous devez faire attention aux UUID. Par exemple, voici ma configuration:

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi
│   ├─debian_crypt-swap (dm-1) 3f9f24d7-86d1-4e21-93e9-f3c181d05cf0   [SWAP]
│   ├─debian_crypt-tmp (dm-2)  93fc8219-f985-45fb-bd5c-2c7940a7512d   /tmp
│   ├─debian_crypt-home (dm-3) 12e8566c-8f0f-45ec-8524-6d9d9ee91eae   /home
│   └─debian_crypt-root (dm-4) 9685570b-4c9e-43ea-815e-49d10dc7a1bf   /

J'ai une partition cryptée (sda2) avec 4 volumes (LVM). Ce dont j'ai besoin, c'est de définir deux UUID dans les bons fichiers. L'UUID sda2 va à /etc/crypttabet l'UUID du volume (par exemple debian_crypt-root) va à /etc/fstab.

Ce serait donc:

# cat /etc/crypttab
sda2_crypt              UUID=727fa348-8804-4773-ae3d-f3e176d12dac   none        luks

# cat /etc/fstab
UUID=9685570b-4c9e-43ea-815e-49d10dc7a1bf       /               ext4    defaults,errors=remount-ro              0 1

Après avoir changé le /etc/crypttabfichier, vous devez reconstruire initramfs:

# update-initramfs -u -k all

REMARQUE

Le package cryptsetupdoit être installé car il contient des scripts de démarrage qui prennent en charge le montage automatique des volumes chiffrés au démarrage.

Pourquoi prendre la peine de mentionner cela? Eh bien, si vous avez installé lors de l'installation LVM Debian Wheezy installe les paquets cryptsetup-bin , libcryptsetup4et lvm2non cryptsetup, vous avez donc les outils pour configurer les périphériques et LVM LUKS mais pas les scripts nécessaires pour monter les périphériques LUKS au démarrage. Ceux-ci viennent dans le paquet cryptsetup .

Mikhail Morfikov
la source
J'ai essayé d'utiliser UUIDmais j'obtiens la même erreur. Je mettrai à jour la question avec des détails.
pgpb.padilla
Salut, cela devient un peu trop long, pouvons-nous discuter ?
pgpb.padilla
En passant, même si vous ne modifiez pas / etc / crypttab, il semble que les disques le modifieront pour vous si vous modifiez certains paramètres de cryptage. Cette réponse m'a aidé à corriger les erreurs que j'ai faites avec les disques (et peut-être plus d'erreurs en essayant d'annuler les disques).
sauge
0

Il semble que la réponse de @Mikhail Morfikov couvre le montage pendant l' étape initramfs . Une alternative (si ce n'est pas le système de fichiers racine) est de décrypter et de monter la partition automatiquement via systemd , après le chargement du noyau linuz. Bien sûr, cela n'est possible que si vous exécutez systemd . Je vais expliquer la méthode ici:

L' /etc/crypttabentrée:

crypt2 UUID=e412-blahblah /path/to/crypt2.key luks,noauto

Voici noautoune instruction pour ne pas essayer de décrypter le disque pendant l' étape initramfs .

Ci-dessus, e412-blahblahl'UUID de la partition contenant le système luks, dans mon cas une partition /dev/sdb2:

# blkid | grep sdb2
/dev/sdb2: UUID="e41274d8-fd83-4632-b560-ad0ba113ae75" TYPE="crypto_LUKS" PARTUUID="5673a908-02"

Au démarrage du noyau linuz, systemd lira le /etc/crypttabfichier et créera un fichier de service d'exécution /run/systemd/generator/[email protected]. Cependant, ce service n'est pas exécuté automatiquement. Vous pouvez l'exécuter manuellement

systemctl start [email protected]

mais pour le décrypter puis le monter au démarrage, il /etc/fstabpeut être nécessaire de le faire comme suit:

/dev/mapper/crypt2--vg-data /media/crypt-data ext4 defaults,noauto,user,x-systemd.automount,[email protected] 0 2

Voici x-systemd.automountune instruction à systemd pour monter /media/crypt-data, et [email protected]une instruction à systemd dont le déchiffrement crypt2est requis avant que cela ne soit possible.

Dans le systemd ne montera pas réellement le répertoire jusqu'à la première fois qu'il est accédé, par exemple ls /media/crypt-data, alors il montera juste à temps et apparaîtra ensuite dans /proc/mounts.

en relation

Vous pouvez demander "* pourquoi avoir un disque de données chiffré avec la clé dans le système de fichiers racine?". C'est parce que le système de fichiers racine est également crypté, donc la clé est sûre. Le système de fichiers racine est décrypté pendant la phase de démarrage initramfs , une réponse de la Mikhail. J'ai une autre entrée dans le /etc/crypttabfichier pour ça:

crypt1 UUID=8cda-blahbalh none luks,discard,lvm=crypt1--vg-root

et je décris la configuration de cela et une clé USB de démarrage ici

Craig Hicks
la source