2

Cryptsetup was working flawlessly for months, but something I did today on my system now makes it hang:

# cryptsetup --debug --verbose luksOpen /dev/sdb home --key-file=/home.key --verbose
...
Key slot 1 unlocked.
...
# Udev cookie 0xd4d949a (semid 32768) decremented to 1
# Udev cookie 0xd4d949a (semid 32768) waiting for zero

Also when I do lsblk -f, I used to get UUIDs for all of the devices (including sdb) but now I only get a UUID and FSTYPE for the rootfs (every other device is listed, but FSTYPE, LABEL, and UUID are empty). blkid however does show the a UUID for all devices.

I also do not see any network devices - eth0 and wlp4s0 are missing from ip link and ifconfig.

When I boot from the original live USB, everything works perfectly - I can mount all partitions, connect to WiFi, and arch-chroot into the broken system. After doing so, I did pacman -Syuu, uninstalled all packages I installed today (f2fs-tools, exfat-utils, fuse-exfat) and updated my initramfs with mkinitcpio -p linux.

  • Did you ever solve this? Was your key-file really /home.key? – airhuff Feb 2 '17 at 5:57
  • I foobared udevd by linking it to /dev/null in systemd. See my answer below. Yes, /home.key was the key-file. No, it's not insecure: full disk encryption and the file is only readable by root. – cronburg Feb 2 '17 at 18:57
1

Stupidity in my .bash_history:

#1448399392
chroot rootfs /bin/bash -x <<'EOF'
ln -s /dev/null /etc/systemd/system/systemd-udevd.service
ln -s /dev/null /etc/systemd/system/systemd-udevd-control.socket
ln -s /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
ln -s /dev/null /etc/systemd/system/proc-sys-fs-binfmt_misc.automount
exit
EOF

Deleted the horrible horrible symlinks and everything's fine now. I accidentally ran the above links on the main system rather than inside the LXC container. (https://wiki.archlinux.org/index.php/Linux_Containers#Systemd_conflicts_in_the_.2Fdev_tree)

1

This Udev cookie ... waiting for zero also happens when any of the following conditions are true:

  1. Your distribution is missing the /lib/udev/rules.d/${NUMBER}-dm.rules file, where ${NUMBER} is 55 in at least Ubuntu 15.10 Wily. (Details)
  2. udev needs to be started with sudo service udev start
  3. udev is running, but needs to be restarted with sudo service udev restart (because you've changed the state of the system's mounted volumes in some way, and Udev needs to reset its state)
  • Interestingly enough I just had the exact same issue (2 years later...) trying to setup an ubuntu installation - the udev rules file isn't installed by default but the cryptsetup binary is. I installed a couple of the device mapper related packages and got the file (libdevmapper-dev, cryptsetup, ...) – cronburg Jun 9 '17 at 12:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.