The Cockpit tests found a regression with this update: Unlocking an encrypted root partition with clevis does not work any more. With 20-2, boot looked like this:
[ OK ] Found device dev-disk-by\x2duuid-6…34326d22e.device - QEMU_HARDDISK 2.
Starting systemd-cryptsetup@luks\x…e492-182e-480e-8b2e-36634326d22e...
Please enter passphrase for disk QEMU_HARDDISK (luks-6233e492-182e-480e-8b2e-36634326d22e): (press TAB for no echo)
it sat there for a bit (30 to 60s? I didn't measure it), then clevis kicks in, gets the key from the tang server, and boot continues. With 21-1, it gets to that point, but then gets stuck in a loop of
Detected no PKCS#11 device, retry PKCS#11 detection? [yY/nN]
[ 244.314441] dracut-initqueue[2805]: No slots.
I can interactively press 'N' and then booting continues. But this interactive question ruins unattended boot, which is the very point of clevis.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
This update has been submitted for testing by sarroutb.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
Works.
This update can be pushed to stable now if the maintainer wishes
The Cockpit tests found a regression with this update: Unlocking an encrypted root partition with clevis does not work any more. With 20-2, boot looked like this:
it sat there for a bit (30 to 60s? I didn't measure it), then clevis kicks in, gets the key from the tang server, and boot continues. With 21-1, it gets to that point, but then gets stuck in a loop of
I can interactively press 'N' and then booting continues. But this interactive question ruins unattended boot, which is the very point of clevis.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Update breaks dracut tang unlock. A hot fix was provided here: https://src.fedoraproject.org/rpms/clevis/pull-request/31
Thanks for the catch, @martinpitt
@martinpitt: May I ask you to retest with next scratch build to verify everything works as expected with proposed fix?: https://koji.fedoraproject.org/koji/taskinfo?taskID=124247945
@sarroutb: That fixes the issue and works fine against our tests, thank you!
Getting this into F41 asap would be very helpful. Just had new kernel update problems which broke both a system using luks and one that doesn't.
This update has been obsoleted by clevis-21-2.fc41.