cryptsetup open hangs waiting for udev cookied

[Dimitri John Ledkov]

systemd has a testcase to setup, open and close a luks1 volume.

this test case has started to fail with udev 237 & cryptsetup2

this appears to be reproducible with straight up "cryptsetup open" call which seems to hang in device mapper library, e.g.:

# cryptsetup open --type luks UUID=fd41c9ba-4286-415d-95e4-960fd28b5e>
# cryptsetup 2.0.1 processing "cryptsetup open --type luks UUID=fd41c9ba-4286-415d-95e4-960fd28b5e43 varcrypt --key-file /etc/varkey --debug --verbose"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/disk/by-uuid/fd41c9ba-4286-415d-95e4-960fd28b5e43.
# Trying to open and read device /dev/disk/by-uuid/fd41c9ba-4286-415d-95e4-960fd28b5e43 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/disk/by-uuid/fd41c9ba-4286-415d-95e4-960fd28b5e43.
# Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.1.
# Detected kernel Linux 4.13.0-32-generic x86_64.
# PBKDF pbkdf2, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 0, parallel_threads 0.
# Reading LUKS header of size 1024 from device /dev/disk/by-uuid/fd41c9ba-4286-415d-95e4-960fd28b5e43
# Key length 32, device size 18432 sectors, header size 2050 sectors.
# Activating volume varcrypt using token -1.
# File descriptor passphrase entry requested.
# Activating volume varcrypt [keyslot -1] using passphrase.
# dm version [ opencount flush ] [16384] (*1)
# dm versions [ opencount flush ] [16384] (*1)
# Detected dm-ioctl version 4.37.0.
# Detected dm-crypt version 1.18.0.
# Device-mapper backend running with UDEV support enabled.
# dm status varcrypt [ opencount flush ] [16384] (*1)
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
Key slot 0 unlocked.
# Calculated device size is 14336 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-fd41c9ba4286415d95e4960fd28b5e43-varcrypt
# Udev cookie 0xd4d4a7f (semid 65538) created
# Udev cookie 0xd4d4a7f (semid 65538) incremented to 1
# Udev cookie 0xd4d4a7f (semid 65538) incremented to 2
# Udev cookie 0xd4d4a7f (semid 65538) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK (0x20)
# dm create varcrypt CRYPT-LUKS1-fd41c9ba4286415d95e4960fd28b5e43-varcrypt [ opencount flush ] [16384] (*1)
# dm reload varcrypt [ opencount flush securedata ] [16384] (*1)
# dm resume varcrypt [ opencount flush securedata ] [16384] (*1)
# varcrypt: Stacking NODE_ADD (253,0) 0:6 0660 [trust_udev]
# varcrypt: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d4a7f (semid 65538) decremented to 1
# Udev cookie 0xd4d4a7f (semid 65538) waiting for zero

[Dimitri John Ledkov (xnox)]

So i've tried various combinations of downgrading systemd/cryptsetup/lvm.

At the moment latest cryptsetup2 and systemd from bionic-proposed, pass the systemd test when downgrading lvm2 (devmapper et al) to the one in artful 2.02.168-2ubuntu3

I am suspecting a regression in lvm2, specifically around udev cookies synchronisation.

[Peter Rajnoha (prajnoha)]

Please, first check if "dmsetup udevcomplete" is called from within udev rules.

To check that, you need to enable udevd debug mode (e.g. configure udev_log="debug" in /etc/udev/udev.conf). Then watch systemd journal for systemd-udevd messages:

   journalctl -f -u systemd-udevd

Then try to run the cryptsetup... You should see dmsetup "udevcomplete call" - if not, something is wrong with udev rules so that that rule is not executed.

[Dimitri John Ledkov (xnox)]

Thank you!

This does appear to be the problem, that 95-dm-notify.rules are now shipped in the package, but were not copied in the test harness.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 237-3ubuntu3

---------------
systemd (237-3ubuntu3) bionic; urgency=medium

  * tests/control: drop qemu-system-ppc.
    Whilst some tests pass, many regress / fail to boot. This is not a regression,
    as qemu-based tests were not run previously.

 -- Dimitri John Ledkov <email address hidden> Tue, 20 Feb 2018 17:40:02 +0000