Back to Dm-crypt.
When encrypting a system it is necessary to regenerate the initial ramdisk after properly configuring mkinitcpio. Depending on the particular scenarios, a subset of the following hooks will have to be enabled:
encrypt: always needed when encrypting the root partition, or a partition that needs to be mounted before root. It is not needed in all the other cases, as system initialization scripts like
/etc/crypttabtake care of unlocking other encrypted partitions.
shutdown: recommended before mkinitcpio 0.16 to ensure controlled unmounting during system shutdown. It is still functional, but not deemed necessary anymore.
keymap: provides support for foreign keymaps for typing encryption passwords; it must come before the
keyboard: needed to make USB keyboards work in early userspace.
usbinput: deprecated, but can be given a try in case
keyboarddoes not work.
Other hooks needed should be clear from other manual steps followed during the installation of the system.
For example using GRUB the relevant parameters are best added to
/etc/default/grub before generating the boot configuration. See also GRUB#Warning when installing in chroot as another point to be aware of when installing the GRUB loader.
This parameter will make the system prompt for the passphrase to unlock the device containing the encrypted root on a cold boot. It is parsed by the
encrypt hook to identify which device contains the encrypted system:
deviceis the path to the raw encrypted device. Usage of Persistent block device naming is advisable.
dmnameis the device-mapper name given to the device after decryption, which will be available as
- If a LVM contains the encrypted root, the LVM gets activated first and the volume group containing the logical volume of the encrypted root serves as device. It is then followed by the respective volume group to be mapped to root. The parameter follows the form of
root= parameter specifies the
device of the actual (decrypted) root file system:
- If the file system is formatted directly on the decrypted device file this will be
- If a LVM gets activated first and contains an encrypted logical rootvolume, the above form applies as well.
- If the root file system is contained in a logical volume of a fully encrypted LVM, the device mapper for it will be in the general form of
deviceis the device file of the decrypted (swap) filesystem used for suspend2disk. If swap is on a separate partition, it will be in the form of
/dev/mapper/swap. See also Dm-crypt/Swap encryption.
This parameter is required by the
encrypt hook for reading a keyfile to unlock the
cryptdevice. It can have three parameter sets, depending on whether the keyfile exists as a file in a particular device, a bitstream starting on a specific location, or a file in the initramfs.
For a file in a device the format is:
deviceis the raw block device where the key exists.
fstypeis the filesystem type of
pathis the absolute path of the keyfile within the device.
For a bitstream on a device the key's location is specified with the following:
cryptkey=/dev/sdZ:0:512 reads a 512 bit keyfile starting at the beginning of the device.
Also note that if
cryptkey is not specified, it defaults to
/crypto_keyfile.bin (in the initramfs).
See also Dm-crypt/Device encryption#Keyfiles.
This parameter is specific to pass dm-crypt plain mode options to the encrypt hook.
It takes the form
The arguments relate directly to the cryptsetup options. See Dm-crypt/Device encryption#Encryption options for plain mode.
For a disk encrypted with just plain default options, the
crypto arguments must be specified, but each entry can be left blank:
A specific example of arguments is
/etc/crypttab (encrypted device table) file is similar to the fstab file and contains a list of encrypted devices to be unlocked during system boot up. This file can be used for automatically mounting encrypted swap devices or secondary file systems.
crypttab is read before
fstab, so that dm-crypt containers can be unlocked before the file system inside is mounted. Note that
crypttab is read after the system has booted up, therefore it is not a replacement for unlocking encrypted partitions by using mkinitcpio hooks and boot loader options as in the case of encrypting the root partition.
crypttab processing at boot time is made by the
# Example crypttab file. Fields are: name, underlying device, passphrase, cryptsetup options. # Mount /dev/lvm/swap re-encrypting it with a fresh key each reboot swap /dev/lvm/swap /dev/urandom swap,cipher=aes-xts-plain64,size=256 # Mount /dev/lvm/tmp as /dev/mapper/tmp using plain dm-crypt with a random passphrase, making its contents unrecoverable after it is dismounted. tmp /dev/lvm/tmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256 # Mount /dev/lvm/home as /dev/mapper/home using LUKS, and prompt for the passphrase at boot time. home /dev/lvm/home # Mount /dev/sdb1 as /dev/mapper/backup using LUKS, with a passphrase stored in a file. backup /dev/sdb1 /home/alice/backup.key
Mounting at boot time
If you want to mount an encrypted drive at boot time, enter the device's UUID in
/etc/crypttab. You get the UUID (partition) by using the command
lsblk -f and adding it to
crypttab in the form:
externaldrive UUID=2f9a8428-ac69-478a-88a2-4aa458565431 none luks,timeout=180
The first parameter is your preferred device mapper's name for the encrypted drive. The option
none will trigger a prompt during boot to type the passphrase for unlocking the partition. The
timeout option defines a timeout in seconds for entering the decryption password during boot.
A keyfile can also be set up and referenced instead of
none. This results in an automatic unlocking, if the keyfile is accessible during boot. Since LUKS offers the option to have multiple keys, the chosen option can also be changed later.
Use the device mapper's name you've defined in
/etc/fstab as follows:
/dev/mapper/externaldrive /mnt/backup ext4 defaults,errors=remount-ro 0 2
/dev/mapper/externaldrive already is the result of a unique partition mapping, there is no need to specify an UUID for it. In any case, the mapper with the filesystem will have a different UUID than the partition it is encrypted in.
Mounting a stacked blockdevice
The systemd generators also automatically process stacked block devices at boot.
$ lsblk -f
─sdXX linux_raid_member │ └─md0 crypto_LUKS │ └─cryptedbackup LVM2_member │ └─vgraid-lvraid ext4 /mnt/backup └─sdYY linux_raid_member └─md0 crypto_LUKS └─cryptedbackup LVM2_member └─vgraid-lvraid ext4 /mnt/backup
will ask for the passphrase and mount automatically at boot.
Given you specify the correct corresponding crypttab (e.g. UUID for the
crypto_LUKS device) and fstab (
/dev/mapper/vgraid-lvraid) entries, there is no need to add additional mkinitcpio hooks/configuration, because
/etc/crypttab processing applies to non-root mounts only. One exception is when the
mdadm_udev hook is used already (e.g. for the root device). In this case
/etc/madadm.conf and the initramfs need updating to achieve the correct root raid is picked first.