Comments
martinpitt
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.
Verified, works. Thanks for the super-fast turnaround!
Works here.
Works here.
Works here.
Upgrades and works fine.
cockpit-machine's nightly run against updates-testing https://github.com/cockpit-project/cockpit-machines/issues/1739 picked up this update and causes a regression with migration. Apparently libvirt cannot run ssh any more:
audit: SELINUX_ERR op=security_compute_sid invalid_context="system_u:system_r:ssh_t:s0" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=process virtqemud[1036]: Cannot recv data: libvirt: error : cannot execute binary ssh: Permission denied: Connection reset by peer
That's hard to say unfortunately, the TF log doesn't print them anywhere: https://artifacts.dev.testing-farm.io/eceffdf6-95df-4eec-a623-a1aaca405ac7/ (presumably because it's not installed, but is part of the base image).
But I suspect it may actually be the unpushed 2.2.0-1.fc41 from FEDORA-2024-3766dd8914 , that mentioned the same problem.
However, even if that is a firewalld problem, the "automated tests" here has 24 failures, including your own (functional): https://artifacts.dev.testing-farm.io/93dcde52-a95e-460f-881f-9f2fcfad0507/
Is there any way to retract this update quickly? This breaks so much, it's rather unbearable..
By the timing and symptoms, I'm also quite sure this is what breaks the stratis tests (like https://github.com/stratis-storage/stratisd/pull/3642 and a handful of others):
+ systemctl start firewalld
+ firewall-cmd --add-service=cockpit --permanent
Error: [Errno 13] Permission denied: '/etc/firewalld/zones/public.xml'
Install, upgrade, and page working fine here.
Upgrade and pages work.
Upgrade and pages work.
Works here.
Regression-tested and confirmed the fix for https://bugzilla.redhat.com/show_bug.cgi?id=2277954 in https://github.com/cockpit-project/cockpit-podman/pull/1768 . Thanks!
I tested upgrading from 316, and a fresh install -- in particular also with a dynamic cockpit-ws user. Dropping cockpit-pcp on i686 is a necessary evil to unblock the upgrade, but pcp has been broken for three weeks anyway (https://bugzilla.redhat.com/show_bug.cgi?id=2284431).
This breaks restarts: https://bugzilla.redhat.com/show_bug.cgi?id=2325556