Comments
martinpitt
Last night's cockpit tests are happy again, too, thanks!
https://cockpit-logs.us-east-1.linodeobjects.com/pull-0-d76cadd5-20241203-013139-fedora-41-updates-testing/log.html https://cockpit-logs.us-east-1.linodeobjects.com/pull-0-e6e46082-20241203-022518-fedora-41-updates-testing/log.html
Verified with our tests, thanks!
Steve: I can reproduce this outside of any tests, in a Fedora 40 or 41 cloud image. https://bugzilla.redhat.com/show_bug.cgi?id=2328627 has a reproducer.
It is also broken in F41, so this regression landed now, see https://bugzilla.redhat.com/show_bug.cgi?id=2328627
Perhaps you can still unpush, but I figure it's too late.
Reported with trivial reproducer in https://bugzilla.redhat.com/show_bug.cgi?id=2328627
Perhaps this already tells you something?
Note: The corresponding F40 update is broken: FEDORA-2024-e27e34f8dc
We don't currently run Cockpit tests on Fedora 41 updates-testing, but there is a high chance that rpc.statd crashes in F41 as well. I don't -1 this right now as I don't have proof yet, but you may want to be cautious.
This causes rpc.statd crashes, so major regression: https://cockpit-logs.us-east-1.linodeobjects.com/pull-0-c7d327f8-20241124-013228-fedora-40-updates-testing/log.html#259
Tracking in https://github.com/cockpit-project/cockpit/issues/21312 . No details yet (it's Sunday after all), but we have to stop this from reaching users.
Install/upgrade works fine.
Together with the libtirpc update the NFS restart works again, so undoing my -1. Thanks!
Together with FEDORA-2024-e8733f31e3 the NFS restart works again, so undoing my -1. Thanks!
Thanks! I confirmed that with nfs-utils-2.8.1-1.rc1.fc40 and libtirpc-1.3.6-1.fc40 update, things are happy again.
This breaks restarts: https://bugzilla.redhat.com/show_bug.cgi?id=2325556
This breaks restarts: https://bugzilla.redhat.com/show_bug.cgi?id=2325556
Install/update/pages work as expected.
This fixes NBDE root reboot.
@sarroutb: That fixes the issue and works fine against our tests, thank you!
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.
rpminspect failures are expected. I sent https://github.com/rpminspect/rpminspect-data-fedora/pull/60 to clear them.