Combining RAID and Crypto using the Etch installer

All these issues should be fixed in current daily builds of the debian-installer and should be history for the Lenny rc1 release of the debian-installer.


Very short version

If you setup a device using a combination of RAID and crypto, you need to manually add an entry to /target/etc/crypttab.

Longer version


There is a bug in the Etch version of DebianInstaller which generates an incorrect configuration if the root file system uses a combination of RAID and crypto, making it impossible to boot into the newly installed system. This has been reported in a number of bug reports (393728, 397872, 398464, 407905, 412948).

Unfortunately the changes necessary to fix this properly are of a magnitude which made them unsuitable to commit to the installer shortly before the release of the Etch installer (when the bug was found and properly diagnosed). However, it is possible to work around the bug manually by following the instructions on this page.

Should you have a morbid curiosity for the internals of the DebianInstaller, a detailed description of the bug is also included at the bottom of the page.


For the rest of this document, we will assume that you wish to perform an installation using two harddrives. Further, it will be assumed that you wish to combine the two disks into a RAID1 device, encrypt that device and create a single root filesystem inside the encrypted virtual device.

Assuming that the two harddrives are /dev/sda and /dev/sdb, the RAID device would normally get a device name like /dev/md0 (the number might differ if you have several RAID devices setup) and the virtual crypto device would then be called /dev/mapper/md0_crypt.

The fix


Perform the installation as usual and set up the RAID/crypto partitioning scheme of your liking by following section 6.3.2 of the installation manual. Make sure that you write down the details on how the crypto filesystem(s) have been setup as you will need this information later.

At the end of the installation, you will be prompted to remove any installation media and to press enter to reboot into your newly installed Debian system. Do not press enter at this point.

Instead, change to VT2 by pressing Alt + F2 followed by Enter. This should drop you into a basic shell.

Gathering information

Now you need to check the device name which has been assigned to the root device, this can be done by executing mount and looking for the device which is mounted on /target:

~ # mount
/dev/mapper/md0_crypt on /target type ext3 (rw,data=ordered)
/dev/mapper/md1_crypt on /target/home type ext3 (rw,data=ordered)

In the above example, /dev/mapper/md0_crypt corresponds to the root device.

Adding the missing information

Now use the included nano editor to edit the file /target/etc/crypttab. If you setup other crypto devices (which did not rely on RAID), this file might already exist.

Add a line of the following format:

<decrypted-root-device-node> <encrypted-root-device-node> <keyfile> <options>

decrypted-root-device-node is the crypto device node which contains the root file system of the installation (/target), in the above example, this would be md0_crypt.

encrypted-root-device-node is the full path to the device node which the crypto device is based on, in our case this would be /dev/md0.

If the crypto is based on LUKS (all crypto installs using a passphrase are), the keyfile should be none and options should be luks (as the key and the options are stored in the luks header).

Consequently, the added line should look something like this:

md0_crypt /dev/md0 none luks

Finishing up

Once the missing line has been added to /target/etc/crypttab, the following commands need to be executed:

~ # chroot /target
sh-3.1# mount /proc
sh-3.1# update-initramfs -u
sh-3.1# umount /proc
sh-3.1# exit
~ #

That's it! Your system should now be properly configured, so change back to VT1 (Alt + F1) and press enter to reboot into your newly installed Debian system.

Technical background

partman, the DebianInstaller partitioning component has a directory which keeps track of all currently known storage devices available in the system. Each time partman is restarted (i.e. after most major changes), it needs to recalculate its current state.

For all other (non-md) devices, partman copies the old information if a device is detected as still being present in the system. However, for md devices, partman clobbers the information and recreates it. This means that the crypto information is also lost, which in turn means that the /target/etc/crypttab entry is never generated.

This might seem easy to fix - simply make sure that partman also copies the information for md devices. However, it is not clear why partman had that special behaviour in the first place and the only way to ensure that changing it does not introduce regressions is through extensive testing which was not feasible so close to the release of the Etch installer.

Therefore, the bug remained, and this page was written to document the workaround. Expect the bug to be quashed in the post-Etch development version of DebianInstaller (and consequently, in the Lenny DebianInstaller version).