crypsetup hangs when only cryptsetup-bin is installed

[Robie Basak]

According to http://ubuntuforums.org/showthread.php?t=2326677, the user types "cryptsetup", is prompted (presumably by command-not-found) to install cryptsetup-bin, and then subsequently the cryptsetup command hangs.

I would expect either cryptsetup-bin to depend on cryptsetup, or for the cryptsetup command to do something more useful than hang.

I have not verified this reported behaviour but thought it worthy of a report.

[Robie Basak (racb)]

(the user reported that this is on Xenial but didn't provide any version numbers)

[Markus Spring (m-spring)]

I can confirm this on 16.04.1 64bit from a fresh minimal install.

* cryptsetup luksFormat works after installing cryptsetup-bin
* cryptsetup luksOpen hangs without further notification

After installation of the Package cryptsetup, 'cryptsetup luksOpen' works as expected.

[Adrien Beau (adrienbeau)]

I can confirm this on 16.04 32bit from a fresh minimal install.

* The container had been working fine for many years on 12.04 32bit
* The container was still working a few days ago before switching to 16.04
* cryptsetup luksOpen hangs without further notification

More accurately, using strace, it appears to be stuck on a semaphore:

# strace -p 8230
strace: Process 8230 attached
semop(65538, [{0, 0, 0}], 1^Cstrace: Process 8230 detached
 <detached ...>

(The hangs appears to happen after the mapper has been created, so one must run cryptsetup luksClose before running another luksOpen command.)

After installing the "cryptsetup" package, everything works fine again. Clearly, "cryptsetup-bin" should Depend on or at least Recommend "cryptsetup".

Ubuntu release: 16.04
Source package: cryptsetup
Package version: 2:1.6.6-5ubuntu2.1

[Adrien Beau (adrienbeau)]

Sorry for the double-posting, the idea only occurred to me after sending my first comment.

Installing the "cryptsetup" package installs several dependencies, including a lot of boot-time stuff I do not need. I wondered if one of the dependencies could solve the problem by itself, and it turns out to be the case.

In order to open a LUKS container and not hang in the process, "cryptsetup-bin" actually only needs "dmsetup" to be installed.

So the Depends or Recommends should be on "dmsetup".

[Roman Fiedler (roman-fiedler-deactivatedaccount)]

Preloading the attached shared library solves the hang on non-udev initrds. Compile with

gcc -shared -fPIC -o no-udev.so UdevDisableLib.c -ldl

Difference seems to be that /dev/mapper/ entries are created a s block devices, not symlinks any more. But that does not hurt in my usecase (kexec will kill the whole initrd immediately afterwards).

[zub (zub-linux)]

This issue breaks encrypted drive support on a LTS release of Ubuntu. The workaround is easy (installing cryptsetup), but finding this bug report is more difficult. So I think this is an important issue.

[zub (zub-linux)]

Cryptsetup hangs like this:

$ sudo cryptsetup -v --debug luksOpen /dev/sdb sdb
... (stuff omitted)
Enter passphrase for /dev/sdb:
# 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 405504 sectors (RW), offset 4096.
# dm versions OF [16384] (*1)
# Device-mapper backend running with UDEV support enabled.
# dm create sdb CRYPT-LUKS1-f2a0b33c4cc846899c500848022f0e6a-sdb OF [16384] (*1)
# dm reload sdb OF [16384] (*1)
# dm resume sdb OF [16384] (*1)
# sdb: Stacking NODE_ADD (253,0) 0:6 0660 [verify_udev]
# sdb: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d949d (semid 0) decremented to 1
# Udev cookie 0xd4d949d (semid 0) waiting for zero

Installing debug symbols and attaching gdb to the cryptsetup process reveals the following callstack:

#0 0x00007fb5ca2b0c47 in semop () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007fb5c9d5c54c in _udev_wait (cookie=223188125) at libdm-common.c:2533
#2 dm_udev_wait (cookie=223188125) at libdm-common.c:2551
#3 0x00007fb5ca78df8b in _dm_create_device (name=name@entry=0x2265700 "sdb", type=<optimized out>, type@entry=0x7fb5ca79998e "LUKS1", device=0x2265520,
    flags=flags@entry=0, uuid=0x2265cb8 "f2a0b33c-4cc8-4689-9c50-0848022f0e6a", size=405504,
    params=0x2267478 "aes-xts-plain64 89e00160708f00e2323202aab3e1a7d115844b5da7d207a2e3576caa3abe4d44 0 /dev/sdb 4096", reload=0) at libdevmapper.c:621
#4 0x00007fb5ca78e476 in dm_create_device (cd=cd@entry=0x2265bd0, name=name@entry=0x2265700 "sdb", type=type@entry=0x7fb5ca79998e "LUKS1",
    dmd=dmd@entry=0x7fffe6e3e280, reload=reload@entry=0) at libdevmapper.c:665
#5 0x00007fb5ca7942a7 in LUKS1_activate (cd=cd@entry=0x2265bd0, name=name@entry=0x2265700 "sdb", vk=<optimized out>, flags=flags@entry=0)
    at keymanage.c:1124
#6 0x00007fb5ca787b67 in crypt_activate_by_passphrase (cd=0x2265bd0, name=0x2265700 "sdb", keyslot=0, passphrase=0x0, passphrase_size=<optimized out>,
    flags=0) at setup.c:1997
#7 0x000000000040864c in ?? ()
#8 0x0000000000402fd0 in ?? ()
#9 0x00007fb5ca1c8830 in __libc_start_main (main=0x402b40, argc=6, argv=0x7fffe6e3e648, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffe6e3e638) at ../csu/libc-start.c:291
#10 0x0000000000403759 in ?? ()

... so it's clearly waiting on a semaphore. Without looking at the code, my guess is that it's waiting for udev to create a node for the device. And that for some reason does not happen.

While cryptsetup is in this state, there is nothing in /dev/mapper except for /dev/mapper/control. But dmsetup ls sees the device:

$ sudo dmsetup ls
sdb (253:0)

... so it really seems to me like the whole trouble is in the creation of the appropriate /dev special file.

When I install cryptsetup, the issue goes away.

Interestingly, the issue also goes away when I mount the disk via the GUI at least once (There is an encrypted disk icon in the panel. Clicking it triggers a popup asking for the password. After I enter the password, the disk is opened correctly.). After that, for some magical reason, cryptsetu...