CRUX : Home

Home :: Documentation :: Download :: Development :: Community :: Wiki :: Ports :: Bugs :: Links :: About

Back to wiki start page Categories: Development

Experimental Support for Cryptsetup

Thomas Penteker

Hello together,

as already stated in IRC I have worked on getting CRUX to optionally provide users to (fully) encrypt their root partition during installation. (There is a tool to accomplish the same for existing installations but it's not fully ready for primetime, as it seems. A tutorial for this could be written later)

The following steps / patches are subject for discussion; I found them to be the ideal way to solve the whole issue. Points were I was uncertain to solve are described at the end of this email.

What's the benefit of these changes?

You will get a fully encrypted root partition which will only allow to be accessed if the propper passphrase is provided on boot time.

Note: you are required to have a separate, unencrypted /boot-partition where your kernel and initrd (it conaints cryptsetup-util and the script to request the password and handle the decryption etc.).

REMAINING ISSUES (with my test-iso)

General outline of the new setup process


  $ fdisk /dev/hd?
  $ mkfs.???? /dev/hd??
  $ mkswap /dev/hd??


  $ fdisk /dev/hd?
  $ modprobe dm-crypt
  $ cryptsetup luksFormat /dev/hd??
  $ cryptsetup luksOpen /dev/hd?? name
  $ mkfs.???? /dev/mapper/name

from now on, don't use /dev/hd?? for mounting but the newly created/'luksOpen-ed' /dev/mapper/name device node


libdevmapper cryptsetup-initrd cryptsetup libgcrypt popt

(or just everything from core and opt for testing)

kernel configuration It is recommended to include all necessary features 'statically', i.e. not as modules.

say at least yes or module to

General setup --->

  [*] Initial RAM filesystem and RAM disk (iniramfs/initrd) support

Device Drivers --->

  Multiple devices driver support (RAID and LVM) --->
    [M/*] Device mapper support
    [M/*] Crypt target support

Note: you also have to include the desired

  Block modes
  Hash modes

in Cryptographic API --->

to be able to decrypt your partitions later. These may be built as modules or statically into the kernel just like device mapper and device mapper crypt portions of your kernel. If you chose to compile them as modules, you have to load them accordingly in the hand-crafted initrd which has to be built after the kernel compilation process

change to /usr/share/cryptsetup-initrd

adjust modules loaded in init (if necessary)


enter partitions that should be decrypted at boot time


cryptsetup luksOpen /dev/hda2 root

When you finished tailoring init and initramfs.lst for your needs run:

$ sed -e "s/#KERNEL_VERSION#/`uname -r`/g" initramfs.lst > initramfs.lst-SED $ /usr/src/linux-`uname -r`/usr/gen_init_cpio initramfs.lst-SED > initrd $ cp initrd /boot

(alternative: cp initrd /boot/initrd-`uname -r`)

adjust your bootloader's config:

  1. lilo.conf

lba32 install=text boot=/dev/hda image=/boot/26


$ lilo

cross your fingers and reboot. From now on CRUX won't boot if the correct

Because I repeated some (stupid) mistakes during the course of implementation and testing, I created a small FAQ for you to save time.

Q: I type in the correct password but cryptsetup only returns: Command failed: No key available with this passphrase. What is wrong?

A: Load the dm-crypt module and the according module for the cipher you chose to encrypt your partition with.

Q: Why may I not use /dev/hda[0-9] as mount point after I encrypted it with cryptsetup(1)?

A: Do not use the encrypted device node but the (transparently) decrypted (i.e. ``luksOpen''-ed) device located in /dev/mapper/*. It is created after running e.g.

    cryptsetup luksOpen /dev/hda2 name

If the correct passphrase is supplied, a new device /dev/mapper/name will appear which can be mounted, mkfs'd and so on.

Q: LILO complains: ``Fatal: device-mapper: only linear boot device supported''

A: check if your /boot is mounted. A fully encrypted '/' requires an unencrypted /boot, thus it has to live on a partition of its own. This partition has to be mounted correctly during lilo's installation into the MBR for obvious reasons.

Now. Where's the links, because ``send links or it didn't happen''?

Q: Why did you call it 2.4.9?

A: Because I did updates for all packages (to the current state) + the kernel (to 2.6.26) which included the patch for squashfs-3.3. I _do_ hope that this will be helpful to the iso-building people (tilman, jaeger?), too.

I will very glady share a git diff for my /usr/src/iso - repo

Feedback is very welcome (IRC, Mail, Edits here, ...)