zbm-dev/zfsbootmenu

cryptsetup hangs on udev cookie

GregorKopka opened this issue · 4 comments

GregorKopka commented

ZFSBootMenu build source

Recovery EFI

ZFSBootMenu version

2.3.0

Boot environment distribution

Problem description

zfsbootmenu-recovery-x86_64-v2.3.0-vmlinuz hangs on cryptsetup luksOpen on
Udev cookie 8xd4d6c78 (semid 0) waiting for zero
(last line of debug output from cryptsetup)

Cause seems to be that device mapper udev rules are missing in the image.

Steps to reproduce

  1. Boot zfsbootmenu-recovery-x86_64-v2.3.0-vmlinuz
  2. cryptsetup luksOpen /dev/... mapper --debug (and enter passphrase) on console
  3. wait for heath death of universe
ahesford commented

I'm still awaiting the completion of Step 3.

In the meantime, do you have any guidance on which udev rules are critical?

  • 😄2
GregorKopka commented

You might want to abort that longing, your system hanging on this will only bring a minuscule speedup (basically rounding to zero) toward thermal equilibrium... so the wait won't be worth it ... 🤣

Given what I have read it could be basically everything device mapper related, so including the /lib/udev/rules.d/${NUMBER}-dm.rules could do the trick. But as my dev lab is currently sitting in a container and I only have this one notebook to play with... I just reverted.

While at it: please add cryptsetup also to the release version, so people can use on-disk encryption.
Native encryption in ZFS (while nice in theory) doesn't seem to be that stable yet, the horrible bugs caused by the encryption code (in severity up to destruction of the whole pool) IMHO need to be weeded out before I feel comfortable using it...

zdykstra commented

If you need full LUKS support in ZFSBootMenu, you'll need to build a local image. We currently do not have any testing infrastructure in place to adequately/easily deploy root-on-ZFS-on-LUKS, so it's not something we can confidently support in the release EFI images.

cryptsetup was added to the recovery images as a nice-to-have helper, but it was obviously unverified. I've removed it from future releases until we have the ability to verify functionality.

GregorKopka commented

Removing a feature is one possible approach if a bug is encountered... though not really an ideal one.
And according to this logic ZFS has to be removed, as there are currently 1122 open issues in the tracker ;)

Is there somewhere information on how to build a local version - and how to control it do include other things?
Preferably not with the docker stack, because last times I tried that I ended up with a build that resulted in the keyboard being completely dead (Lenovo Yoga)...