Christophe HENRY

Ce site ne comporte aucune information d’intérêt, sauf pour celui qui la cherche — Ĉi-retejo ne enhavas informon interesan, krom por iu kiu ĝin serĉas — This website doesn’t have any information of interest, except for who looks for it

Recover a broken crypt boot in Debian

05/04/2013 - Aucun commentaire

I've got encrypted disks that runs a Debian system. All things went fine until I remove /etc/crypttab. I thought it was useless because this file is in an encrypted volume. Why would the system need this file if it's not reachable at boot? Indeed, I was wrong.

It worked until the next kernel update. Since then, I had to manually mount the encrypted stuff before the kernel loads.
cryptsetup luksOpen /dev/xxx diskName luks none
lvm
vgchange -ay diskName
The fatal kernel update ran update-grub which rebuilds that initrd image. This image is loaded at the very start, before the kernel itself, to provide it with useful things like access to the encrypted data! The initrd must be told to handle the encryption: which disks, which way to encrypt, which logical volume, and so on. This configuration was precisely erased when the update-grub did not see any /etc/crypttab. Of course, I put it back again but nothing worked anymore.

The solution is to modify the initrd at /conf/conf.d/cryptroot with:
target=disk_crypt,source=/dev/disk,key=none,lvm=my-lvm
I installed a Debian inside a virtual machine (Virtual Box) with an approaching configuration to get clues.

Tags de l'article :

Recover a broken crypt boot in Debian

05/04/2013 - Aucun commentaire

I've got encrypted disks that runs a Debian system. All things went fine until I remove /etc/crypttab. I thought it was useless because this file is in an encrypted volume. Why would the system need this file if it's not reachable at boot? Indeed, I was wrong.

It worked until the next kernel update. Since then, I had to manually mount the encrypted stuff before the kernel loads.
cryptsetup luksOpen /dev/xxx diskName luks none
lvm
vgchange -ay diskName
The fatal kernel update ran update-grub which rebuilds that initrd image. This image is loaded at the very start, before the kernel itself, to provide it with useful things like access to the encrypted data! The initrd must be told to handle the encryption: which disks, which way to encrypt, which logical volume, and so on. This configuration was precisely erased when the update-grub did not see any /etc/crypttab. Of course, I put it back again but nothing worked anymore.

The solution is to modify the initrd at /conf/conf.d/cryptroot with:
target=disk_crypt,source=/dev/disk,key=none,lvm=my-lvm
I installed a Debian inside a virtual machine (Virtual Box) with an approaching configuration to get clues.

Tags de l'article :