systemd gets stuck mounting veracrypt encrypted volume

blueflame6531 · 2022-11-28 19:11:06

Hello,

I have an encrypted partition (by VeraCrypt) with an NTFS filesystem that I would like to mount at boot.

My system is fully up-to-date and I am running linux-zen kernel with root on ZFS (which works as expected).

I have added it (my encrypted volume) to /etc/crypttab:

# 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>

# encrypted vol
archive1 /dev/sdd1 none tcrypt-veracrypt

Additionally, I have added it to /etc/fstab:

# Static information about the filesystems.

# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

# /dev/nvme0n1p1

UUID=4DC5-12B5 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2

# encrypted vol
/dev/mapper/archive1 /e ntfs3 defaults 0 0

Upon boot, I am prompted for my password for the volume (/dev/mapper/archive1). It succeeds and opens the encrypted volume at /dev/mapper/archive1.
However, it gets stuck forever at "A start job is running for /dev/mapper/archive1" (mounting the volume?)

When the /dev/mapper/archive1 entry is removed from /etc/fstab the normal boot process will complete.
After this I can manually mount it using

mount -t ntfs3 /dev/mapper/archive1 /e

and my volume is mounted at /e.
If I add the entry back to /etc/fstab and run

mount -a

it works as expected.

If the entry is added back to /etc/fstab (and is no longer mounted at /e) and I attempt

systemctl daemon-reload
systemctl start e.mount

The start command will hang without output.
Here is the generated systemd-cryptsetup@archive1.service file:

# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
After=cryptsetup-pre.target systemd-udevd-kernel.socket
Before=blockdev@dev-mapper-%i.target
Wants=blockdev@dev-mapper-%i.target
Conflicts=umount.target
Before=cryptsetup.target
BindsTo=dev-sdd1.device
After=dev-sdd1.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'archive1' '/dev/sdd1' 'none' 'tcrypt-veracrypt'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach 'archive1'

Here is the generated e.mount file from systemd (/run/systemd/generator/e.mount)

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
After=blockdev@dev-mapper-archive1.target

[Mount]
What=/dev/mapper/archive1
Where=/e
Type=ntfs3

Here is journalctl -b output from a boot with entries present in /etc/crypttab and /etc/fstab (it gets stuck at 13:42:50, after 3 minutes I rebooted the system):
https://pastebin.com/raw/T5N8VfDB

hiob · 2022-11-28 22:26:52

I had a similar issue with recent updates.
Replacing "sd-lvm2" with "lvm2" in the HOOKS in /etc/mkinitcpio.conf fixed it for me (I got the idea from deprecation warnings from the output of `pacman -S systemd`)

cfr · 2022-11-30 03:13:56

https://wiki.archlinux.org/title/VeraCr … cryptsetup suggests you might need different options in crypttab but note the warning at the top of the page about (parts of?) it being outdated.

blueflame6531 · 2022-11-30 19:50:10

hiob wrote:

I had a similar issue with recent updates.
Replacing "sd-lvm2" with "lvm2" in the HOOKS in /etc/mkinitcpio.conf fixed it for me (I got the idea from deprecation warnings from the output of `pacman -S systemd`)

I am not using lvm2/sd-lvm2 unless "autodetect" is adding it to my HOOKS

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
HOOKS=(base udev autodetect modconf block keyboard zfs filesystems)

cfr wrote:

https://wiki.archlinux.org/title/VeraCr … cryptsetup suggests you might need different options in crypttab but note the warning at the top of the page about (parts of?) it being outdated.

I updated crypttab to specify options as 'tcrypt,tcrypt-veracrypt', it works as before, it is opened at /dev/mapper/archive1
I updated fstab to specify options as 'noauto,x-systemd.automount', I can boot to display manager but upon accessing the mount path (/e) the shell will hang as it can't be mounted

As a workaround for myself I just made a systemd unit to run the mount commands manually, and that works well enough for me.
However I would still like to discover the issue with systemd being unable to mount my encrypted volumes.

Last edited by blueflame6531 (2022-11-30 19:51:18)

cfr · 2022-11-30 20:16:39

blueflame6531 wrote:

I can boot to display manager but upon accessing the mount path (/e) the shell will hang as it can't be mounted

Which shell? Is this before you log in using the display manager? Is it waiting for you to supply a password to decrypt the volume? If that's happening before you're in the GUI, does it have any way to get the password from you? Or is this after you login to X or Wayland?

blueflame6531 · 2022-11-30 20:51:50

cfr wrote:

blueflame6531 wrote:
I can boot to display manager but upon accessing the mount path (/e) the shell will hang as it can't be mounted
Which shell? Is this before you log in using the display manager? Is it waiting for you to supply a password to decrypt the volume? If that's happening before you're in the GUI, does it have any way to get the password from you? Or is this after you login to X or Wayland?

I think I worded that poorly, but I was using bash. Anything will hang waiting for systemd to automount the volume (e.g. Chrome as my theme is on my encrypted volume) as it can't mount it for some reason. This is after I have already logged in (I am using GDM and Gnome) with noauto,x-systemd.automount in my fstab for the entry. It does not prompt me for my password when systemd tried mounting the volume to /e as I am prompted for it during boot because of my crypttab entry.

Last edited by blueflame6531 (2022-11-30 20:53:05)

ezacaria · 2023-06-27 14:39:05

I had a similar problem today, except that my partition is an old one encrypted with truecrypt. When trying to access the mount point, the automount gets stuck and never completes.

Perhaps the problem is that "--key-file" (or "-d") does not seem to work as we think it should, when "cryptsetup open" is in truecrypt/veracrypt mode.

I tried to open the volume with the password inside a file (the volume has just the password, no key file in use):

cryptsetup open --type tcrypt /dev/nvme1n1p3 tc-data -d pathToFileWithThePassword

And I get prompted for the password - as reported in this issue.

On the other hand, when the crypttab entry does not have the "noauto", I get prompted for password at boot but the volume fails to open - like the manual try above.

Leaving out the -d, however, works:

cryptsetup open --type tcrypt /dev/nvme1n1p3 tc-data

I get prompted for password, and the volume opens. However, this is not suitable for automation.

Hopefully, I am not necro-bumping this one.

Last edited by ezacaria (2023-06-27 14:44:11)

Arch Linux

#1 2022-11-28 19:11:06

systemd gets stuck mounting veracrypt encrypted volume

#2 2022-11-28 22:26:52

Re: systemd gets stuck mounting veracrypt encrypted volume

#3 2022-11-30 03:13:56

Re: systemd gets stuck mounting veracrypt encrypted volume

#4 2022-11-30 19:50:10

Re: systemd gets stuck mounting veracrypt encrypted volume

#5 2022-11-30 20:16:39

Re: systemd gets stuck mounting veracrypt encrypted volume

#6 2022-11-30 20:51:50

Re: systemd gets stuck mounting veracrypt encrypted volume

#7 2023-06-27 14:39:05

Re: systemd gets stuck mounting veracrypt encrypted volume

Board footer