Difference between revisions of "Dm-crypt/Encrypting an entire system"

From ArchWiki
Jump to: navigation, search
m (Setup encryption: fixing link)
(Fill the mapped device: content link to dm-crypt generalised instructions)
Line 376: Line 376:
{{Note|It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to. See [[Disk_Encryption#Preparing_the_disk]] for a more comprehensive discussion.}}
{{Note|It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to. See [[Disk_Encryption#Preparing_the_disk]] for a more comprehensive discussion.}}
{{Warning|The following operation will destroy all data on the underlying physical disk.}}
In this case, with /dev/mapper/enc, we use:
# dd if=/dev/zero of=/dev/mapper/enc
# cat /dev/zero > /dev/mapper/enc
Use of {{ic|/dev/urandom}} is not required here, as anything written to the mapped device is passed through the encryption cipher before being written to disk.
When the process is finished, you may wish to check to see if any existing partition table has been wiped:
See [[Dm-crypt/Drive_Preparation]] and [[Dm-crypt/Drive_Preparation#dm-crypt_specific_methods]]
# fdisk -l
{{Note| The partition table will only have been wiped if the offset was set to 0. As a side effect of this, the disk will no longer be addressable by UUID, however it can still be addressed by physical ID ({{ic|/dev/disk/by-id}}).}}
=== Install the system ===
=== Install the system ===

Revision as of 21:39, 3 December 2013

Back to Dm-crypt.

Simple partition layout with LUKS

This install example covers the a full system encryption with dmcrypt+LUKS in a simple partition layout. Most of the installation of an encrypted system partition can be carried out normally. However, there are a few areas where it is important to make certain selections.

Preparing the disk

Prior to creating any partitions, securely erase the disk as described in Dm-crypt/Drive Preparation#Secure erasure of the hard disk drive (the necessary tools are on the installation ISO).

Then create the needed partitions, at least one for / (e.g. /dev/sdaX) and /boot (/dev/sdaY), following the Installation Guide.

Preparing non-boot partitions

Check if the blockdevice mapper dm_mod is loaded with:

# lsmod | grep mod

Then follow the same procedure described in details in Dm-crypt/Encrypting a non-root file system#Partition:

# cryptsetup -y -v luksFormat /dev/sdaX
# cryptsetup open /dev/sdaX cryptroot
# mkfs -t ext4 /dev/mapper/cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

Check the mapping works as intended:

# umount /mnt
# cryptsetup close cryptroot
# cryptsetup open /dev/sdaX cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

If you created separate partitions (e.g. /home), these steps have to be adapted and repeated for all of them, except for /boot.

See Dm-crypt_with_LUKS/Encrypting_a_non-root_file_system#Automated_unlocking_and_mounting for automated unlocking and mounting of additional partitions at boot.

Note that each blockdevice requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via crypttab. See Dm-crypt/Device Encryption#Using LUKS to Format Partitions_with a Keyfile for instructions.

Preparing the boot partition

What you do have to setup is a non-encrypted /boot partition, which is needed for a crypted root. For a standard MBR/non-EFI /boot partition, that may be achieved by formatting:

# mkfs -t ext2 /dev/sdaY

Creating a mount-point for installation:

# mkdir /mnt/boot

And mounting it:

# mount -t ext2 /dev/sdaY /mnt/boot

That is basically what is necessary at this point before continuing the installation from Installation Guide#Mount the partitions. Take care to install the boot loader to /mnt/boot with the pacstrap script. Additional configuration steps must be followed before booting the installed system.

Configuring mkinitcpio

Add the encrypt hook to mkinitcpio.conf before filesystems; also add shutdown:

HOOKS="... encrypt ... filesystems ... shutdown ..."

See dm-crypt/System Configuration#Configuring mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to enable booting an encrypted root partition, the following kernel paramaters need to be set. See kernel parameters for instructions specific to your boot loader.

The main parameter is cryptdevice, with the following syntax:

  • device is the path to the raw encrypted device. Usage of Persistent block device naming is advisable.
  • dmname is the device-mapper name given to the device after decryption, which will be available as /dev/mapper/dmname.

So if the encrypted root device in the example is /dev/sda2 and the decrypted one should be mapped to /dev/mapper/cryptroot, the kernel parameter would be:


This will make the system prompt for the passphrase to unlock the root device on a cold boot.

Depending on the setup other parameters are required as well:

cryptdevice=device:dmname root=device resume=device cryptkey=device:fstype:path
  • root=device is the device file of the actual (decrypted) root file system. If the file system is formatted directly on the decrypted device file this will be /dev/mapper/dmname.
  • resume=device is the device file of the decrypted (swap) filesystem used for suspend2disk. See also Dm-crypt/Swap Encryption.
  • cryptkey=device:fstype:path is required for reading a keyfile from a file system. See also Dm-crypt/Device Encryption#Using Cryptsetup with a Keyfile.
    • device is the raw block device where the key exists.
    • fstype is the filesystem type of device (or auto).
    • path is the absolute path of the keyfile within the device.

Checking fstab

Further, double-check the genfstab script's result for your /dev/mapper/cryptroot and other mounts. See also fstab.


Merge-arrows-2.pngThis article or section is a candidate for merging with Encrypted LVM#LVM on LUKS.Merge-arrows-2.png

Notes: Content here comes from this revision, check any later updates to the article before redirecting it here. (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

The straight-forward method is to set up LVM on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot.

This method will not allow you to span the logical volumes over multiple disk, even in the future. For a solution that allows to do so, see #LUKS on LVM.

Preparing the disk

Prior to creating any partitions, securely erase the disk as described in Dm-crypt/Drive Preparation#Secure erasure of the hard disk drive (the necessary tools are on the installation ISO).

Then make the following partitions:

  • sdx1 - Size 2MB, Partition Type EF02 (This is so GRUB plays nice with GPT)
  • sdx2 - Size 200mb, Partition Type 8300 (This is your /boot partition)
  • sdx3 - Remaining space, Partition Type 8E00 (LVM)

After that, create the LUKS encrypted container (sdx3. We do not encrypt /boot or the BIOS partition)

# cryptsetup luksFormat /dev/sdx3

NOTE: cryptsetup has a TON of options (which you can find in its man page). The defaults now are quite secure (aes-xts-plain64 with 256bit keysize results in a 128 bit AES encryption for the data), but you may change whatever settings you like here. A description of the options you find in the LUKS page too. Enter your password twice.

Now we open our container:

# cryptsetup open --type luks /dev/sdx3 lvm

Your decrypted disk is now available at /dev/mapper/lvm

Preparing the logical volumes

# pvcreate /dev/mapper/lvm
# vgcreate MyStorage /dev/mapper/lvm
# lvcreate -L 15G MyStorage -n rootvol
# lvcreate -L 35G MyStorage -n homevol
# lvcreate -L 200G MyStorage -n mediavol
# mkfs.ext4 /dev/mapper/MyStorage-rootvol
# mkfs.ext4 /dev/mapper/MyStorage-homevvol
# mkfs.ext4 /dev/mapper/MyStorage-mediavol
# mount /dev/MyStorage/rootvol /mnt
# mkdir /mnt/home
# mount /dev/MyStorage/homevol /mnt/home
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
|Logical volume1 15GB  |Logical volume2 35GB      |Logical volume3 200GB               |
|/dev/MyStorage/rootvol|/dev/MyStorage/homevol    |/dev/MyStorage/mediavol             |
|_ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|                                                                                      |
|                        (LUKS Encrypted Disk  /dev/sdxx)                              |
|                                                                                      |

Preparing the boot partition

In most setups, a dedicated /boot partition is not necessary, but it is in a complex setup like this one, because GRUB needs to be able to read the kernel, initramfs, it's own configuration files, etc. from the /boot directory. Since GRUB does not itself know how to unlock a LUKS partition (that's the kernel's job), /boot must not be encrypted, and therefore must be a separate disk partition.

Create an ext2 filesystem on the partition you created for /boot earlier (/dev/sdx2 in the example above).

# mkfs -t ext2 /dev/sdx2

Mount this partition under the /boot partition of the installed system. If you skip this step (or if you mount /mnt after /mnt/boot), GRUB's installation scripts will be writing to the root partition's /boot directory, which will be encrypted and thus unreadable by GRUB at the next reboot. Note: you may wish to delete the /boot/* directory contents from /dev/sdx3 (root partition) to make it obvious that /boot is not mounted, in case you need to make changes in the future.

# mount /dev/sdx2 /mnt/boot #if you are outside the chroot, OR
# mount /dev/sdx2 /boot     #if you are inside the chroot

Now continue through the Arch setup. (Pacstrap, arch-chroot /mnt, and so on. This HOWTO will assume you are also installing grub-bios to GPT as per the install guide.)

Configuring mkinitcpio

Add the encrypt and lvm2 hooks to mkinitcpio.conf, before filesystems; also add shutdown:

HOOKS="... encrypt lvm2 ... filesystems ... shutdown ..."
Note: In the past, it was necessary to ensure the correct ordering of the encrypt and lvm2 hooks, but the order no longer matters with the current implementation of lvm2.

See dm-crypt/System Configuration#Configuring mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

Now we need to tell the kernel which partition contains the encrypted root file system, so it can be unlocked at boot. You should use Persistent block device naming, rather than /dev/sdx3. For example, to use the UUID, run the blkid command to get the UUID of the encrypted partition. You'll see something like:

# blkid
# /dev/sdx3: UUID="e239b6b6-f7a9-473a-a17d-872de2982c46" TYPE="crypto_LUKS" PARTUUID="0005ea07-05"

Next, edit /etc/default/grub and change the following line to say:

# GRUB_CMDLINE_LINUX="cryptdevice=/dev/disk/by-uuid/e239b6b6-f7a9-473a-a17d-872de2982c46:MyStorage"
Note: If you are not using grub, you will need to have a "root=" parameter as well. The reason grub2 does not require this is because the auto-generated grub.cfg is meant to handle specifying the root for you.


# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx
Note: You may receive warnings like "/run/lvm/lvmetad.socket: connect failed: No such file or directory" or "WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning" when running these commands. This because /run is not available inside the chroot. These warnings will not prevent the system from booting (provided everything has been done correctly), so you may continue with the installation.

Checking fstab

"genfstab -p /mnt >> /mnt/etc/fstab" will make the proper entry in fstab, so that no further manual intervention is needed and the /boot partition is automatically mounted when the system starts.


Merge-arrows-2.pngThis article or section is a candidate for merging with Encrypted LVM#LUKS on LVM.Merge-arrows-2.png

Notes: Content here comes from this revision, check any later updates to the article before redirecting it here. (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

To use encryption on top of LVM, the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well. Unlike #LVM on LUKS, this method allows normally spanning the logical volumes over multiple disks.

The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for /tmp and /swap. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.

Preparing the disk

Partitioning scheme:

  • /dev/sda1 -> /boot
  • /dev/sda2 -> LVM

Randomise /dev/sda2:

cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2
dd if=/dev/urandom of=/dev/mapper/lvm
cryptsetup remove lvm

Preparing the logical volumes

lvm pvcreate /dev/sda2
lvm vgcreate lvm /dev/sda2
lvm lvcreate -L 10G -n root lvm
lvm lvcreate -L 500M -n swap lvm
lvm lvcreate -L 500M -n tmp lvm
lvm lvcreate -l 100%FREE -n home lvm
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root
cryptsetup open --type luks /dev/lvm/root root
mkreiserfs /dev/mapper/root
mount /dev/mapper/root /mnt

Note that /home will be encrypted after rebooting.

Preparing the boot partition

dd if=/dev/zero of=/dev/sda1 bs=1M
mkreiserfs /dev/sda1
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot

Now after setup of the encrypted LVM partitioning, it would be time to install: Arch Install Scripts.

Configuring mkinitcpio

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Does the order of lvm2 and encrypt matter in this case? Compare to Dm-crypt/Encrypting an entire system#Configuring mkinitcpio 2. (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

Add the lvm2 and encrypt hooks to mkinitcpio.conf, before filesystems; also add shutdown:

HOOKS="... lvm2 encrypt ... filesystems ... shutdown ..."

See dm-crypt/System Configuration#Configuring mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

For the above example, change the kernel options for the root-device auto-configured in the bootloader installation from root=/dev/hda3 to

cryptdevice=/dev/lvm/root:root root=/dev/mapper/root

More general, the kernel command line for LUKS <-> LVM is constructed like this:

root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group>

For example:

root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg

Or like this:

cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root

If you want install the system on a usb stick, you need to add lvmdelay=/dev/mapper/lvm-root

Configuring fstab and crypttab

 /dev/mapper/root        /       reiserfs        defaults        0       1
 /dev/sda1               /boot   reiserfs        defaults        0       2
 /dev/mapper/tmp         /tmp    tmpfs           defaults        0       0
 /dev/mapper/swap        none    swap            sw              0       0
 swap	/dev/lvm/swap	SWAP		-c aes-xts-plain -h whirlpool -s 512
 tmp	/dev/lvm/tmp	/dev/urandom	-c aes-xts-plain -s 512

Encrypting /home after reboot

Below we will be editing /etc/crypttab. This is necessary to unlock each non-root LUKS container (like /home, /media, etc) -- these logical volumes are just as important as /root, and if they are not visible the entire system will fail to boot! LVM must have all volumes present and accounted for. Now, in order to avoid typing in multiple passwords (1 per container) every boot, we may generate some strong encryption keys and save them in /etc. Some more background about possible encryption keys, you find here. When the PC is powered off, these keys are perfectly safe: they are being saved inside the root LVM container, which must be unlocked by you at boot with a password. As well, having different passwords for each disk makes breaking the encryption even more difficult -- even if one password is compromised, the LVM WILL NOT activate without the other partitions.

mkdir -p -m 700 /mnt/etc/luks-keys
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home
cryptsetup open --type luks -d /etc/luks-keys/home /dev/lvm/home home
mkreiserfs /dev/mapper/home
mount /dev/mapper/home /home
 home	/dev/lvm/home   /etc/luks-keys/home
Note: If you do not want to use a keyfile, simply leave the third column empty (/etc/luks-keys/home in the example) and you will be asked for a password at boot.
 /dev/mapper/home        /home   reiserfs        defaults        0       0

Expanding LVM on multiple disks

The encrypt hook only allows for a single cryptdevice= entry. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS container. This is perfectly fine for a single-drive system: there is only one container to decrypt. But what happens when you want to increase the size of your LVM? This is in fact the main advantage of LVM: you can add and remove entire drives without having to change the underlying partition.

So, you add another hard drive in order to expand home (which is a logical volume of its own). You encrypt the second drive, add it to the volume group, expand the home LV. But now, how do you tell initrd to unlock BOTH drives at the same time? You cannot, at least not without modifying the encrypt hook. And as stated in the section above: if only a part of an LVM is available, it will not boot. So, adding a second drive that requires decryption before it can be read is out of the picture.

Luckily, we can get around this by making the LVM's visible to the system even before they are encrypted. This is why LUKS on LVM is, in general, the option offering more flexibility to change partitioning.

Adding a new drive

Assuming you now have a working single-drive LUKS-on-LVM configuration, it's now time to expand one of your logical volumes.

Connect your drive (if it's new, or completely randomize it as you did with your root drive). Open gdisk and create a single partiion:

  • /dev/sdy1: Use ALL space, Partition type 8E00 (Linux LVM)

Now, attach this new disk to your existing LVM:

# pvcreate /dev/sdy1
# vgextend MyStorage /dev/sdy1

Extending the logical volume

You will have to unmount whatever partition you want to grow, meaning you may need to boot via an install cd. Details for this will follow below. In this example, we will extend the "HOME" logical volume by 100% of the free space of our new drive (ie, put the WHOLE thing into /home!)

From a root console:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Now the LV is extended. Let us make LUKS aware of the change:

# cryptsetup open --type luks /dev/mapper/MyStorage-homevol home
# cryptsetup --verbose resize home

And finally resize the ext4 partition itself:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home


# mount /dev/mapper/home /home

Note how /home now includes the span of the new drive, and you DO not have to change or add any more encryption keys -- the key for your Home LVM will continue to work and fill into the newly added space.

  • A note on extending your root partition:

The procedure works exactly the same for your root LVM, with the exception that it must be done from an Arch INSTALL CD. (you can't unmount your root partition while it's in use).


The system does not boot

First, DONT PANIC! You can always boot a rescue CD and get into your LVM manually!

Start up via the Arch installer. When you reach the root shell, for each encrypted LVM:

# cryptsetup open --type luks /dev/mapper/MyStorage-rootvol

Simply unlock each logical partition -- they will appear in /dev/mapper/<lv> and you can mount each from there.

LUKS on software RAID

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Plain dm-crypt

Merge-arrows-2.pngThis article or section is a candidate for merging with Plain dm-crypt without LUKS.Merge-arrows-2.png

Notes: Content here comes from this revision, check any later updates to the article before redirecting it here. (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

This article focuses on system disk encryption using plain dm-crypt without LUKS. Note that for most use cases, the methods using LUKS described above are by far better options for both system encryption and encrypted partitions. Below are some considerations for choosing one over the other.


  • dm-crypt does not require a header on the encrypted disk. This means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data. This may be useful in a country that can force you to give up an encryption key where a reasonable suspicion of encrypted data exists.
  • plain dm-crypt encrypted disks are more resilient to damage than LUKS encrypted disks, because of the one-to-one mapping of unencrypted data to encrypted data.


  • dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.
  • plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.
  • LUKS uses pass-phrase salting and hash iteration, and as such can be more secure than plain dm-crypt. It is essential that a pass-phrase or key-file with very high entropy is used with dm-crypt.

A separate /boot partition is required, as it needs to remain unencrypted to be accessed by the bootloader. In the scenario that follows, it is assumed that no evidence of encryption is to be left on the main system drive, and so we install the /boot partition and the bootloader to a separate USB stick, and the encryption key to yet another USB stick. Throughout the guide, the system disk will be shown as /dev/sdX, the USB stick containing /boot will be shown as /dev/sdY, and the USB stick containing the encryption key will be shown as /dev/sdZ, where X, Y and Z represent their respective device letters.

Setup encryption

Dm-crypt does not need a partition table and the existence of one could provide a reasonable suspicion that the drive is encrypted. We therefore set up the encryption directly on the physical disk. If a partition table already exists on the target disk, it will be wiped when we later fill the disk.

See Dm-crypt/Device Encryption#Encryption options for plain mode for details.

Example with default options

Using default options with the device /dev/sdX and using enc for the mapped name, we have:

# cryptsetup open --type plain /dev/sdX enc

You will then be prompted for a password twice, which should have very high entropy. See https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects for details.

Example with custom options

If custom options are required, you may wish to test which encryption system works best on your system:

# cryptsetup benchmark

Using the device /dev/sdX, with the twofish-xts cipher with a 512 bit key size we have:

# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:

# fdisk -l

An entry should now exist for /dev/mapper/enc.

Fill the mapped device

Note: It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to. See Disk_Encryption#Preparing_the_disk for a more comprehensive discussion.

See Dm-crypt/Drive_Preparation and Dm-crypt/Drive_Preparation#dm-crypt_specific_methods

Install the system

Much of the following steps are identical to those in the Installation Guide. Where they differ is:

  • the target installation device is the mapped device under /dev/mapper/* instead of the physical device /dev/sdX;
  • /boot and the bootloader will be installed to a USB stick;
  • the initramfs hook encrypt is added to mkinitcpio.conf;
  • the details of the encryption are added to the kernel options in the bootloader.

Partition disks

See Partitioning for further details.

You may use fdisk to create a standard partition table on the mapped device:

# fdisk /dev/mapper/enc

However, a more flexible approach is to use LVM:

# pvcreate /dev/mapper/enc
# vgcreate store /dev/mapper/enc
# lvcreate -L 20G store -n root
# lvcreate -C y -L 10G store -n swap
# lvcreate -l +100%FREE store -n home

See Lvm#Installing_Arch_Linux_on_LVM for further details.

For the remainder of this guide we will use the simple LVM volume set created above, which will have created the volumes /dev/store/root, /dev/store/home and /dev/store/swap. The choice of volume group name and logical volume names are arbitrary.

The /boot partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required:

# fdisk /dev/sdY
> n
> p
> 1
> default (2048)
> +200M
> w
> q

Format the partitions

See File Systems#Format a device for further details.

In our example, we will simply use ext4 for root and home.

# mkfs.ext4 /dev/store/root
# mkfs.ext4 /dev/store/home

And for the /boot partition, if not already formatted as vfat, we choose a non-journalling file system to preserve the flash memory:

# mkfs.ext2 /dev/sdY1

And lastly the swap partition, if required:

# mkswap /dev/store/swap
# swapon /dev/store/swap

Mount the partitions

We are now in a position to mount the partitions and begin the standard Arch installation process.

# mount /dev/store/root /mnt
# mkdir /mnt/home
# mount /dev/store/home /mnt/home
# mkdir /mnt/boot
# mount /dev/sdY1 /mnt/boot

Install and configure the base system

Please follow Installation Guide#Install the base system until editing mkinitcpio.conf is required, then add encrypt to the HOOKS array as follows:

HOOKS="base udev ... encrypt ... filesystems ..."

For this example we also require the lvm2 hook:

HOOKS="base udev ... encrypt lvm2 ... filesystems ..."

Then rebuild the initramfs as per usual:

# mkinitcpio -p linux

Install and configure the bootloader

See Installation Guide#Install and configure a bootloader and then return to this guide.

The kernel arguments for initialising a plain dm-crypt disk are as follows:

cryptdevice=/dev/sdX:<mapped name>

Where /dev/sdX is the physical disk containing the encrypted data, and <mapped name> is the name once mapped to /dev/mapper/<mapped name>.


Which one used will depend on whether the key has been written as a file to a partition, or as a bit stream to unpartitioned space. See here for details on different keyfiles.


Here, the arguments hash, cipher, keysize, offset and skip relate directly to the cryptsetup options --hash, --cipher, --key-size, --offset and --skip.

Example with defaults

For a disk encrypted with just default options, we can use the following kernel arguments:

cryptdevice=/dev/sdX:enc crypto=::::

The crypto argument must still be specified, but each entry can be left blank. This will prompt for the pass-phrase on boot.

Example custom options

Assuming the key file is located on /dev/sdZ and the options are as used in the previous example, we have:

cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:

If using grub, this is added to /etc/default/grub:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:"

You may also wish to add:

GRUB_CMDLINE_LINUX="... root=/dev/store/root"

Although it should not be necessary.

This can then be used to update grub.cfg

# grub-mkconfig -o /boot/grub/grub.cfg

The bootloader can then be installed on the same USB as the /boot partition:

# grub-install --recheck /dev/sdY


You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the following option can be added to the boot options in /etc/fstab:

# /dev/sdYn
UUID=************* /boot ext2 noauto,rw,noatime 0 2

However, when an update to the kernel or bootloader is required, the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with:

# mount /boot