I have been having a lot of issues getting an encrypted multi-disk root filesystem to boot up reliably under systemd on Debian Jessie while only having to enter the password once. Previously I've handled this in Debian by using the decrypt_derived keyscript in /etc/crypttab for every device except the first, and this worked well.

However, this does not play well when systemd is introduced. systemd-cryptsetup-generator does not handle keyscripts, and when trying to find more information about how to solve this, I only found vague references to some custom password agent in an email from one of the systemd developers which only gives the unhelpful advice that it is "easy to write additional agents. The basic algorithm to follow looks like this" and then a list of 13 steps to take. Clearly not meant for an end user.

I Debian, I have got it to work to some degree by playing with a couple of kernel options that tells systemd to ignore /etc/crypttab during boot, or ignore it completely. Debian's update-initramfs will copy the keyscript to the initramfs and unlock the devices before systemd takes over, but I have found that it leads to issues later because systemd now does not have any unit files for the decrypted devices so mounts that rely on them sometimes seem to hang or get delayed. One place where this breaks is when trying to mount btrfs subvolumes; they are mounted from the same physical device as root, but systemd is not aware that the devices are already unlocked, and halts at boot.

TL;DR - my actual question:

What is the systemd way to handle an encrypted root filesystem spanning multiple devices (be it a btrfs system, LVM mirror, etc) where you only need to enter the password once? I hardly consider this to be an exceptionally unusual case, so here's hoping that there is a method in place to do this.

Some possible solutions comes to mind:

  • Tiny encrypted partition containing a keyfile, which is unlocked before root. The root devices would refer to this keyfile. How would I tell this to systemd?
  • Some sort of caching password agent running in initramfs, which remembers the password and hands it to all devices needing it at boot.
  • Someone has already written a systemd agent emulating decrypt_derived. How would I integrate this in my boot procedure?

I do run Debian exclusively, but after having tried for days to find a solution to my problem I feel that this is perhaps a more system wide problem.

2 Answers 2


This is a well known problem, currently without solution.

On Debian (and other systems), systemd fails to assemble an encrypted BTRFS array, because of the parallel processes and various tests. All the volumes of a BTRFS array must be present for it to be mounted (properly), but as all the volumes of the BTRFS array have the same UUID (by design), systemd try to mount the first volume that it opens without waiting for the others (which would expose the same UUID, confusing systemd even more).

Currently, the only way to use encrypted BTRFS volumes on Debian is to not use systemd (packages sysvinit-core, systemd-shim, etc.). There is no possible "systemd way".

  • 1
    Thank you. I have been experimenting more with this since I posted the question, and I've decided to stay away from an encrypted root for now. I could probably make it work in some form with my new systemd-knowledge, but I want my server to reliably boot up. I will wait a bit with accepting this answer, hoping that someone will claim that it is bullshit and that someone fixed systemd, but eventually I might have to give up hope. :)
    – pipe
    Dec 24, 2015 at 0:59

There is now a solution to this problem (at least in Ubuntu 18.04+, so I assume Debian, and CentOS-7). Described here. Quoting:

Systemd ... will unlock all additional LUKS partitions if

  1. all of the partitions you want to unlock use the same password
  2. you enter the password for the root partition correctly the first time. If you get it wrong, you'll need to enter it again for every other LUKS partition
  • Thank you, I've actually used this for many years already, maybe I should have written a self-answer!
    – pipe
    Aug 12, 2019 at 13:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .