Gentoo Wiki


This article is part of the HOWTO series.
Installation Kernel & Hardware Networks Portage Software System X Server Gaming Non-x86 Emulators Misc


Fully crypted Gentoo on EVMS with lvm2 and raid1


In this Howto I describe what to do, to set up a system on 2 SATA drives (sda, sdb, both 160GB) + 1 IDE drive (hda, 200GB). The system shall be bootable from the SATA drives, which will be in a raid1 (mirroring). There currently is only one IDE drive, but another 200GB IDE drive will be added later (hdb). The IDE drives are going to create another raid1. Over both raids there shall be a lvm2 layer, which hosts all "logical volumes" except from /boot. All mountables in the lvm2 container shall be crypted.

EVMS Setup

Proceed as normal in the handbook, boot from the Gentoo 2006.1 livecd with "gentoo doevms2" boot option, to the step where you're to partition your Harddisk.

Startup the


application from a root terminal in X or


from a terminal.

First of all: This guide focusses on a complete new installation, so we'll delete all the Volumes in the Volumes tab, except the /dev/evms/loop0, as its mount point is /mnt/livecd, meaning it's the livecd ;) Alternatively you can shrink existing volumes to have enough freespace for your installation.

A (logical) Volume is mountable, so this is what we finally want to create, but there are a few steps in between.

Go to the Disk tab, and remove the segment managers from hda, sda and sdb (right-click). Then add a new DOS segment manager to each of them (Actions/Add/Segment Manager to Storage Object), type Linux. This will allow you to create segments:

First partitioning (split boot and other disk space)

Right-click on each of the freespaces in the Disks tab and create segments on them. On hda create a full size segment, Partition Type "Linux", doesn't need to be bootable, Primary Partition. On both sda and sdb create 2 segments, one with 256 MB for the later boot partition with Partition Type "Linux", bootable, primary. The other one with the rest of your freespace, Type "Linux", not bootable, primary.

Raid 1

In the Available Objects tab you should now have 5 entries, hda1, sda1, sda2, sdb1 and sdb2. We will now create 3 raid1 regions, one for sda1, sdb1 (later boot), one for sda2, sdb2 and one for hda1 in degraded mode.

Click on Actions/Create/Region.../MD Raid 1 Region Manager, next and select sda1 and sdb1, next, select Version 1 Super Block, this one is NOT degraded, as we have 2 disks for it... Create! Repeat the steps with sda2 and sdb2. And now repeat it once more for hda1 only, this times set the degraded mode to YES, Missing disk index 1.

Create boot partition

Now first lets create the boot partition. Right-click on md/md0 and select "Create Compatibility Volume...". Go to the Volumes tab and right-click /dev/evms/md/md0 and "Make File System...". Ext2 should do, name it "boot" and deselect Ext3 Journal, as that's a bit much for the 128 MB boot partition. (Some can argue that a raid1 for boot is overkill as well, but... well, it's more symmetric like this ;) )

LVM2 Container over 2 Raid1s

Now lets create a LVM2 Container of our two left over raids md1 and md2. Actions/Create/Container.../LVM2 Region Manager, select md1 and md2, next, name it pstorage. The Extent-size for the new LVM2 container is the size of the later chunks which are mapped to your later logical volumes. So if you set the Extent-size to 32 MB, you won't be able to create a 48 MB logical Volume, as that were 1.5 Extents. In case of later snapshotting this is also the size of the chunks which will be rewritten each time something is modified for the first time, so 32 MB seems pretty ok.

Partitioning / Creating Regions in your LVM2 Container

Go to the Regions tab and notice the lvm2/pstorage/Freespace, which has the size of our combined raid1s. Right-click it, and now create regions:

Always keep in mind, that you can theoretically resize these "partitions" without much work. Growing is normally easier than shrinking. If you like, choose other sizes or leave some Regions out.

Create EVMS Volumes

Now go back to the Available Objects tab and create EVMS Volumes from each of the available Objects (right-click). You can name them as you want, I'd recommend using the names as before, so call /dev/evms/lvm2/home "home", so it becomes the volume /dev/evms/home.

WARNING: DO NOT name any of the EVMS volumes "root", as this will create a wrong /dev/mapper/root (all evms devices also appear under /dev/mapper). This would conflict with the init-rd which will try to map whatever crypted_root you specify (in this case probably /dev/mapper/root) to the uncrypted /dev/mapper/root. (See section Init ramdisk which mounts crypted root for more info.)

OK, if you _don't want_ any crypted file systems you're nearly done... go back to the Volumes tab and make file systems for each of your logical volumes. So I myself chose ReiserFS for all Volumes except the swap space, which is SWAPFS. But actually you can go with whatever filesystem you want, it's a matter of taste ;)

If you _want_ crypted file systems, you don't need to make filesystems yet, as the partitions will be crypted later and the created filesystems would be overwritten.

After that you're done with the evms configuration, click on Actions/Save..., have a look at the details, and then "commit" your changes. This could take quite some time, as you created pretty many partitions, file systems, etc.

Crypt Setup

OK, now let's get started, with the crypting stuff. Get a root shell and cd into your /dev/evms directory. In there you should find the files home, media, slash, swap, tmp and usr. We want to crypt all of them.


First overwrite the first few MBs of each of those partitions with random data. If you want you can overwrite the whole partitions with /dev/urandom, but that should take way too long. (/dev/urandom gives about 4MB/s on my system, so that would to overwrite around 300 GB ... well, do the maths) I'll take a different approach below. So:

for i in home media slash tmp usr vartmp
	dd if=/dev/urandom of=$i bs=1M count=10

Swap will be treated differently: It will be recreated with a random key everytime you boot up your computer. You could also do this with tmp and var/tmp partitions, but I like to clean them myself. So:

dd if=/dev/urandom of=swap

LUKS Setup

Now luksFormat, that means create, all partitions (except swap) like this:

for i in home media slash tmp usr vartmp
	cryptsetup -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/evms/$i

Use a STRONG passphrase, as it's a weak point in the whole encryption of your harddisk. If you want you may use different passwords for all partitions, or e.g. a manual password for your later root partition and a random keyfile for all other partitions which is kept safe in your crypted root-partitions. But for now let's setup all partitions with the same passphrase, so in case anything goes "horribly" wrong, you still know how to access your data. As we use luks it's very easy to change the keys later.

Decrypt / Open LUKS devices

Then open (decrypt) all partitions with:

for i in home media slash tmp usr vartmp
	cryptsetup luksOpen /dev/evms/$i decrypt$i

This method requires entering your PW quite often, but it's just for setup, we'll change this later, so you only need to provide the PW once.

Further initialization / fillup

After that's done, let's use shred to fill the uncrypted partitions with some data, so that they seem to be full when viewing the crypted data:

cd /dev/mapper
for i in decrypt*
	do shred -n 1 -v $i

This will still take a long time, but shred's "random" seems to be way faster than /dev/urandom. If it's lacking a bit of enthropy: no matter to worry, as it still will be crypted, right... There's another approach telling to use "dd if=/dev/zero of=$i bs=1M", which is known to be faster.

Go and have a break... eat something, as this will still take hours (but at least not days ;) ).

Setup swap

If you can't wait, open another shell and set up the temporary swap, which could be useful while running from a live-cd:

cryptsetup create -c aes-cbc-essiv:sha256 -s 256 -d /dev/urandom decryptswap /dev/evms/swap

This will create a normal dm-crypt setup with a random key. Notice that you don't need to provide the key to "open" this device as with luks... So it's perfectly fine to just read the key from /dev/urandom. Also note that the order is a bit whirled around in comparison to luks.

mkswap decryptswap
swapon /dev/mapper/decryptswap

Well, now you really might want to have a break, as we still need to wait for the partitions to fill up.

Creating filesystems

After the partitions are initialized correctly, start setting up the filesystems of your choice, as explained in the Gentoo Handbook. I'll use reiserfs on all partitions except from boot (which is already properly set up by evms) and swap:

for i in decrypthome decryptmedia decryptslash decrypttmp decryptusr decryptvartmp
	do mkreiserfs $i

Mount filesystems

All filesystems are created now, so mount them.

mount /dev/mapper/decryptslash /mnt/gentoo
cd /mnt/gentoo
mkdir -p boot tmp usr home var/tmp
mount /dev/evms/md/md0 boot
mount /dev/mapper/decrypttmp tmp
mount /dev/mapper/decryptusr usr
mount /dev/mapper/decrypthome home
mount /dev/mapper/decryptvartmp var/tmp
mkdir -p usr/local/media
mount /dev/mapper/decryptmedia usr/local/media
chmod 1777 tmp
chmod 1777 var/tmp

Well... You're done for now, as all created partitions are mounted. Continue with the handbook to the section where installing your kernel.



As we've set up a system with encrypted root, we need to create a ram-disk that supports: evms + crypt to access, decrypt and mount your root filesystem. Once root is mounted, it will take over and the other paritions will be loaded by decrypting them with a keyfile which resides in the root partition. As there seems to be a bug with cryptsetup-luks < 1.0.4, where you're not correctly prompted for passwords with kernels later 2.6.20[1], I'd suggest to check whether a more recent version is installed. Else unmask this ebuild (substitute ~amd64 with ~x86, etc. according to your arch):

echo "=sys-fs/cryptsetup-luks-1.0.4-r3 ~amd64" >> /etc/portage/package.keywords

I'd also suggest to use genkernel to create the ramdisk, but first install the needed packages:

USE="-gtk -ncurses -dynamic" emerge --ask --verbose evms cryptsetup-luks

The USE-Flags shown will help you _not_ to install all dependencies right now, you can leave them away in a production system.


Genkernel supports various ways of building your kernel. If you want you can copy the config of the current kernel you're running or the one from your live-cd or you could configure a new kernel yourself. The following command line will not delete the .config file in your kernel-source directory, cause "menuconfig" to ask you for the right settings, save your config to /etc/kernels/... and most important: it will build an initrd with support for evms and luks.

genkernel --no-clean --menuconfig --save-config --evms2 --luks all

Kernel Settings

As you'll get into the Kernel's configuration menu, make sure you have the following options turned on (for luks and evms support):

Device Drivers  --->
 Multi-device support (RAID and LVM)  --->
  [*] Multiple devices driver support (RAID and LVM)
  <M>   RAID support
  <M>     Linear (append) mode
  <M>     RAID-0 (striping) mode
  <M>     RAID-1 (mirroring) mode
  <M>     RAID-10 (mirrored striping) mode (EXPERIMENTAL)
  <M>     RAID-4/RAID-5/RAID-6 mode
  [*]       Support adding drives to a raid-5 array
  <M>     Multipath I/O support
  <M>     Faulty test module for MD
  <*>   Device mapper support
  [*]     Device mapper debugging support
  <*>     Crypt target support
  <M>     Snapshot target (EXPERIMENTAL)
  <M>     Mirror target (EXPERIMENTAL)
  <M>     Zero target (EXPERIMENTAL)
  <M>     Multipath target (EXPERIMENTAL)
  < >       EMC CX/AX multipath support (EXPERIMENTAL)
  <M>     Bad Block Relocation Device Target (EXPERIMENTAL)
 Block Devices -->
  <M> Loopback device support
  <M>   Cryptoloop Support
  <M> RAM disk Support
  (16)  Default number of RAM disks
  (4096) Default RAM disk size (kbytes)
  (1024) Default RAM disk block size (bytes)
  [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
Cryptographic options --->
 --- Cryptographic API
 <*>   SHA256 digest algorithm
 <*>   SHA384 and SHA512 digest algorithms
 <*>   Blowfish cipher algorithm
 <*>   AES cipher algorithms
 <*>   AES cipher algorithms (x86_64)

If you're using other crypt-algorithms, make sure to include them.


Follow the Gentoo manual again to the point where you configure your /etc/fstab... here's mine:

/dev/evms/boot              /boot            ext2          noauto,noatime                    1 2
/dev/mapper/root            /                reiserfs      noatime                           0 0

/dev/mapper/decryptswap     none             swap          sw                                0 0

/dev/mapper/decryptusr      /usr             reiserfs      noatime                           0 2
/dev/mapper/decrypttmp      /tmp             reiserfs      noatime                           0 2
/dev/mapper/decryptvartmp   /var/tmp         reiserfs      noatime                           0 2
/dev/mapper/decryptmedia    /usr/local/media reiserfs      noatime                           0 2
/dev/mapper/decrypthome     /home            reiserfs      noatime                           0 2

/dev/cdroms/cdrom0          /mnt/cdrom       auto          noauto,ro,user                    0 0
/dev/cdrw                   /mnt/cdrw        auto          noauto,user                       0 0
/dev/fd0                    /mnt/floppy      auto          noauto,user                       0 0

proc                        /proc            proc          defaults                          0 0
shm                         /dev/shm         tmpfs         nodev,nosuid,noexec               0 0

Notice line "/dev/mapper/root / ...", this is _needed_ by genkernel's initrd.scripts which will do a cryptsetup luksOpen <crypt_root> "root". Also pay special attention to the "0 0", as with a "0 1" my system didn't work. If you _want_ to know what happens when using the initrd is started up, have a look at the files /usr/share/genkernel/generic/linuxrc /usr/share/genkernel/generic/initrd.scripts, the latter file explains how the crypted /dev/evms/slash is decrypted to /dev/mapper/root. See the startLUKS()-function. (Basically "/dev/mapper/root" is hard-coded in there.)

Bootup config

For now continue with the Gentoo-Handbook to the section where configuring your boot-loader. I'll use Grub as a matter of taste, but I'm sure there are ways how to get things to work with Lilo as well.

Init ramdisk which mounts crypted root

So here's one of my grub.conf boot-entries:

title=Gentoo Linux genkernel x86_64-2.6.19-gentoo-r5
root (hd2,0)
kernel /kernel-genkernel-x86_64-2.6.19-gentoo-r5 root=/dev/ram0 init=/linuxrc ramdisk=8192 crypt_root=/dev/evms/slash real_root=/dev/mapper/root udev doevms2
initrd /initramfs-genkernel-x86_64-2.6.19-gentoo-r5

As you can see there's a whole bunch of options passed to the kernel... If you _want_ a bit of explaining: root (hd2,0) is /dev/sdb in this configuration. As soon as I plug in hdb this will be sda, but as it's a raid1 the same boot partition can be found... ;) crypt_root=/dev/evms/slash tells the linuxrc script to use luks and it will ask you for its password in the initrd.scripts openLUKS()-function. (In there's a line "cryptsetup luksOpen ${LUKS_DEVICE} ${LUKS_NAME}", where the first var will be "/dev/evms/slash" and the latter "root" (as called from the startLUKS()-function). So crypt_root is meant to be set to the EVMS Volume, which represents the crypted rootfs. doevms2 is needed for the EVMS Volumes to be detected and activated. real_root="/dev/mapper/root" seems to be optional in this config, as it would be set to this value anyways (in startLUKS())

Decrypting other evms-Volumes with /etc/conf.d/cryptfs

OK, now that we're kind of sure that our rootfs gets opened when booting, we still have a bunch of other partitions that need to be uncrypted before mounting. Note that if you chose not to use cryptsetup-luks>=1.04, this file has a different syntax, see history So let's configure /etc/conf.d/cryptfs:

options="-c aes-cbc-essiv:sha256 -s 256 -d /dev/urandom"






The file recently was updated and now includes pretty many examples. Still I'll explain a bit... More info can be found in /lib/rcscripts/addons/, which is started as add-on in checkfs and localmount initscripts: First some general info: lines starting with "swap=" or "target=" start a new section PLUS they define the name of the crypt-device in /dev/mapper. First the swap partition: It will create the file /dev/mapper/decryptswap from device /dev/evms/swap. The will recreate this (meaning set up a completely new crypt and swapfs) on every boot. As we just want to open it once, we'll use /dev/urandom as key-data.

All other sections up there are target sections, which will use luks to decrypt the EVMS Volumes with encrypted filesystems to a mapper device. You no more need a type="luks" line, as in earlier versions. The devices are now tested with luks' isLuks option whether they have a valid luks header. If that's the case luks is used to decrypt them. So /dev/evms/home is decrypted to a file called /dev/mapper/decrypthome. In these sections the key is read from a file called /root/hdpw. (see the manpage of cryptsetup for more info.)

Setting up keyfiles / Automatic decryption from root filesystem

If you're now asking yourself where the f*** that keyfile came from, indeed... we didn't create that file and set it up correctly, so let's do that now: Either create your keyfile with some editor like "nano /root/hdpw" or do "dd if=/dev/random of=/root/hdpw bs=1 count=512" or do whatever you like to create that file. Most important here is, that it's harder to guess the files content than your "human readable" passphrase. You might want to "chmod 400 /root/hdpw", but in any way, make sure that this keyfile is a valid keyfile for your partitions. Do this by adding it as a key:

for i in home media tmp usr vartmp
	cryptsetup luksAddKey /dev/evms/$i /root/hdpw

You'll have to provide your passphrase, to decrypt each partitions Master-Key, which will then be encrypted with your new keyfile, so it can be stored in keyslot 1.

Install Grub

After you've done all of this, you'll still need to install Grub into the MBR of the HD you select to boot from in your bios. In my case hda's MBR will be modified to hold GRUB, as I somehow couldn't set my BIOS to booting from sda. I had to do this manually as grub-install failed, so do:

root (hd2,0)
setup (hd0)

root is the device where your /boot partition resides, so in this case /dev/sdb. As mentioned above: I'm going to plug in another 200GB IDE drive: /dev/hdb, so hda will be hd0, hdb will be hd1, sda will be hd2 then.

Cleanup, Reboot

OK, nearly done, unmount all mounted /dev/mapper/decrypt* devices, then exit the chroot and unmount /mnt/gentoo/{dev,proc,}. Don't forget to run cryptsetup luksClose on /dev/mapper/{root,decrypt*}.

Reboot and hope. If anything goes right, you'll be prompted to enter your passphrase. Note: Keyboard layout is: english.


If something goes wrong, don't panic, your data is still on that disk... just that it's crypted atm. So use the live-cd again, get root,

cryptsetup luksOpen /dev/evms/slash root
for i in tmp usr vartmp
	cryptsetup -d /mnt/gentoo/root/hdpw luksOpen /dev/evms/$i decrypt$i
mount /dev/mapper/root /mnt/gentoo
mount -t proc none /mnt/gentoo/proc
mount -o bind /dev /mnt/gentoo/dev
chroot /mnt/gentoo /bin/bash
source /etc/profile
mount -a
mount boot

Welcome back to your gentoo environment ;)

Very poor performance of filesystem actions

In case you encounter problems with the Gentoo 2006.1 liveCD with very poor performance when extracting the stage3-Tarball or the portage snapshot in a LUKS Partition on top of a RAID1: I had a problem, where HD-transactions came to a halt, while I was not at the PC, doing stuff. If you have the same problem, try starting / stopping some applications, which always caused good performance in my case again. This just occurred with the Kernel on that liveCD, neither with a Kubuntu LiveCD, from which I actually installed the system, nor with any later Kernel in the running system.


Retrieved from ""

Last modified: Fri, 05 Sep 2008 22:00:00 +0000 Hits: 11,769