Works well and unbreaks cockpit-podman.

logs

• The above sssd-infopipe error is fixed by https://src.fedoraproject.org/rpms/cockpit/pull-request/27
• TestServices.testBasic gets fixed by https://github.com/cockpit-project/cockpit/pull/14338

I'm still investigating why the libvirt default network disappears. This happens upstream as well in rare occasions, but is some race condition.

Oops, this looks like a regression in sssd:

+ busctl call org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users FindByCertificate s -- "$(cat /var/lib/cockpittest/alice.pem)" | sed 's/^o "//; s/"$//' 
?[0;1;31mCall failed: The name is not activatable?[0m

I tested downloading and unpacking the previous podman-1.9.3 and running it with toolbox-0.0.18-3.fc32.noarch and conmon-2.0.18-1.fc32.x86_64 , but that does not work either. I rebuilt my OSTree entirely without updates-testing, now with podman-1.9.3-1.fc32.x86_64, toolbox-0.0.18-2.fc32.noarch, and conmon-2.0.17-1.fc32.x86_64 and things work again.

This completely breaks toolbox --verbose enter:

toolbox: /home is a symbolic link to /var/home
toolbox: calling org.freedesktop.Flatpak.SessionHelper.RequestSession
toolbox: creating container fedora-toolbox-32
Error: invalid config provided: Groups and privileged are mutually exclusive options
toolbox: failed to create container fedora-toolbox-32

This is happens on a system with rm -rf ~/.local/share/containers ~/.config/containers. On my previously existing config and fedora toolboxes, toolbox enter fails with

toolbox: invalid entry point PID of container sid

and I get all sorts of "permission denied" errors, like

+ echo toolbox: binding /etc/machine-id to /run/host/etc/machine-id
toolbox: binding /etc/machine-id to /run/host/etc/machine-id
+ [ ro =  ]
+ mount_o=-o ro
+ mount --rbind -o ro /run/host/etc/machine-id /etc/machine-id
mount: drop permissions failed.
+ echo toolbox: failed to bind /etc/machine-id to /run/host/etc/machine-id
toolbox: failed to bind /etc/machine-id to /run/host/etc/machine-id
+ return 1

or

+ echo toolbox: removing password for user martin
toolbox: removing password for user martin
+ passwd --delete martin
passwd: Permission denied.

I verified that FIPS mode works again, thanks! https://github.com/cockpit-project/bots/pull/983

cockpit-bridge is missing patternfly.css, which breaks cockpit-composer and every other consumer of that. Tracked in https://github.com/cockpit-project/cockpit/issues/14229

cockpit-bridge is missing patternfly.css, which breaks cockpit-composer and every other consumer of that. Tracked in https://github.com/cockpit-project/cockpit/issues/14229

This broke FIPS mode -- but too late now. I reported it as https://bugzilla.redhat.com/show_bug.cgi?id=1845806

https://bugzilla.redhat.com/show_bug.cgi?id=1839805

Meh, this breaks authentication against AD. But too late now, I'll file a bugzilla.

Gating tests fail, they need an update: https://src.fedoraproject.org/rpms/cockpit/pull-request/20

This is not a failure of cockpit itself though, just that we forgot to update the tests before releasing.

This failure of testUsed is persistent:

+ parted -s /dev/sda mktable msdos
+ parted -s /dev/sda mkpart primary ext2 1M 25
+ udevadm settle
+ echo einszweidrei | cryptsetup luksFormat /dev/sda1
Cannot wipe header on device /dev/sda1.

This is an actual regression in Rawhide, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1824878 for it.

Please ignore the previous comment, that was meant for cockpit-podman, not this update.

Should be fixed in FEDORA-2020-721117fd92

I just pushed a fix to dist-git to drop the bogus "dist.rpmdeplint" required test. Not sure if/when greenwave picks that up, or of it needs to be explicitly re-triggered.

Initial tier-0 test has some flakes. A retry looks different, but even worse. This needs some deeper analysis and probably dialing back the tests a bit.

Yay, no crashes any more! Thanks!

Breaks kdump, same regression as reported a week ago in Fedora 32: https://bugzilla.redhat.com/show_bug.cgi?id=1812393 . However, back then I thought it was kexec-tools to blame.

I just saw that this has already been in testing for a month, so it's probably not kexec-tools itself. I think dracut (https://bodhi.fedoraproject.org/updates/FEDORA-2020-b36b25de24) is a more likely candidate. So undoing my -1.