Boot no more possible: Failed to start Cryptography Setup for lvm

I have a computer running with 4 LVs & LUKS. After entering the password for LV1, the subsequent ones should be decrypted automatically with the configuration in /etc/crypttab.
Since this morning it does not work anymore. I have not made any config changes. I can’t say for sure if Manjaro has applied updates in the background.

The boot process aborts with:

A password is required to access the lvm_desktop1 volume:
Enter passphrase for /dev/sda5:
/dev/mapper/lvm_desktop1-root: clean, 596951/2441216 files, 7512707/9764864 bloc
[FAILED] Failed to start Cryptography Setup for hd_data01.
[DEPEND] Dependency failed for /dev/mapper/hd_data01.
[DEPEND] Dependency failed for /home/wolf/hd_data01.
[DEPEND] Dependency failed for NFS server and services.
[DEPEND] Dependency failed for NFSv4 ID-name mapping service.
[DEPEND] Dependency failed for NFS Mount Daemon.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for File System Check on /dev/mapper/hd_data01.
[DEPEND] Dependency failed for Local Encrypted Volumes.

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.

Pressing Ctrl+D only repeats the message You are in emergency mode, so I commented out my 3 Data LVs in the /etc/fstab` and system boots again.

These are the 3 Data LVs in my /etc/crypttab including the keyfile:

sudo cat /etc/crypttab
[sudo] Passwort für wolf: 
# Configuration for encrypted block devices.
# See crypttab(5) for details.

# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf).

# <name>       <device>                                     <password>              <options>
hd_data01      UUID=f93e2547-350f-450c-9c62-710699fd7b66    /etc/cryptkey_hd_data01    luks,allow-discards
hd_data02      UUID=f9316ae0-6e50-4920-8fc7-d2fd3466dada    /etc/cryptkey_hd_data02    luks,allow-discards
hd_data03      UUID=b89b77cb-951e-45c5-89ea-612099deea70    /etc/cryptkey_hd_data03    luks,allow-discards

It’s possible to open the 3 Data LVs manually (password entry) and also with the keyfile - like the boot process should do:

sudo cryptsetup --key-file-/etc/cryptkey_hd_data01 luksOpen /dev/sde hd_data01

So it seems there is a bug/problem in LVM or the syntax whatever changed.

Can somebody help me or give me a hint what changed?

Manjaro does not apply any updates without your knowledge.

I’ve also edited your text for readability and now hopefully someone with more LUKS experience than me will be able to help you further. (Enschuldigung…)


Thank you. To be honest I tried to format the text much better. But the syntax here and the input elements are not so easy to understand. Or I’m jsut to stupid :smiley:

I don’t know if updates were processed because I was away from home for 2 weeks. So first boot with these problems were two weeks after the last shutdown …

So this is the Bug which leads to my problems: FS#70272 : [systemd] 248-1 breakes LUKS with keyfile
It has been fixed for systemd v249.

Where do I get the information when it will be fixed in Manjaro?

The answer to that question is always: When it’s ready

You can guess how soon it will be available by using this tool:

and there I can see that systemd is currently 248.3, but 249-1 is around the corner in Testing


and once it hits Stable-staging the time will become “very soon”.



Hey Fabby, thanks for your explanation! That makes it understandable for me.
I will wait. I don’t have any other possibility.

So I hope my Manjaro will be able to boot without user interaction again after 1 month.
P.S: It’s the first time after 10 years of Linux, that my productive system is in a non-working state.

1 Like

You can simply switch branches to testing for the time being if this bothers you much.
Switch back to stable once systemd 249 hits that branch.

1 Like

Please read this:

So you’ll never be in a non-working state again!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.