ci: several changes related to new qemu test, ansible-lint, python versions, ubuntu versions

[richm]

There is a new QEMU based test which uses the qemu/kvm capability of
github action runners. This is the basis for new bootc/image mode tests
which we will be rolling out in the near future.

ansible-lint requires that the collection path is set so that the requirements
it installs are installed in the correct place.

There has been some general github action deprecation of python versions and
ubuntu versions that we have had to fix.

Remove CONTRIBUTOR from the list of users who can trigger citest.

For more information, see

• ci: ansible-lint needs collection path; tox-lsr 3.5.1 .github#98
• ci: Run QEMU tox integration tests in GitHub workflow .github#94
• Apply a stricter policy to who can run the workflow .github#93
• ci: Remove tft trigger capability for contributors .github#92
• ci: Drop explicit "connection:" for provisioning .github#91

[martinpitt]

The f42 failure reproduces locally. Journal is a bit sparse, it just says

kdumpctl[1553]: kdump: mkdumprd: failed to make kdump initrd
kdumpctl[1553]: kdump: Starting kdump: [FAILED]

I'm running sh -x kdumpctl start directly, but even that doesn't give much info. It also fails really fast, I don't think it even starts dracut. Not sure where that set +x comes from, it breaks debugging, but it's not part of /usr/bin/kdump nor /usr/lib/dracut/dracut-functions.sh.

+ dinfo 'No kdump initial ramdisk found.'
+ set +x
kdump: No kdump initial ramdisk found.
kdump: Rebuilding /boot/initramfs-6.14.0-63.fc42.x86_64kdump.img
kdump: mkdumprd: failed to make kdump initrd
kdump: Starting kdump: [FAILED]

Hitting /usr/lib/kdump/kdump-logger.sh over the head reveals that it calls

/sbin/mkdumprd -f /boot/initramfs-6.14.0-63.fc42.x86_64kdump.img 6.14.0-63.fc42.x86_64

which fails silently. This is an internal program without --help or manpage. sh -xing it is completely inscrutable.

Maybe there's a config option which it doesn't like. Original:

# grep -v ^# /etc/kdump.conf.2385.2025-04-14@05\:33\:52~ 
auto_reset_crashkernel yes
path /var/crash
core_collector makedumpfile -l --message-level 7 -d 31

From lsr:

path /var/crash
auto_reset_crashkernel yes
failure_action reboot
dracut_args --kernel-cmdline nopti

So the core_collector option is missing (but the default value is just that according to kdump.conf(5)), and the "nopti" looks a bit weird, but that value is explicitly checked in the tests, so presumably that's ok. failure_action also looks legit.

Commenting out all options except path still fails. Adding core_collector fails. Copying the original backup file /etc/kdump.conf.2385.2025-04-14@05:33:52~ fails. So I'd say it's not the config.

/proc/cmdline has crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M which is presumably ok. It's what I get with kdumpctl reset-crashkernel on a clean F42 cloud image. But when rebooting after that, it fails the same way. This is completely independent from lsr.

As it happens, this broke Cockpit's tests last week as wel, and Marius already reported it to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2357959 . So the test really just reproduces this.