Fix two external issues breaking cfs on latest f44+#2195
Conversation
dracut 109 (shipped in Fedora 45, and now backported to Fedora 44 via
FEDORA-2026-5e95ea992d) removed `systemdsystemconfdir` from
01-dist.conf, leaving the variable empty in the dracut build
environment. Our module-setup.sh used that variable for the
`initrd-root-fs.target.wants/` directory, so the symlink was written
to the root of the initramfs rather than under
/usr/lib/systemd/system/. systemd does not recognize root-level .wants
directories, so bootc-root-setup.service was silently never activated,
causing the system to drop to emergency mode on composefs+UKI boots.
Switch to `${systemdsystemunitdir}` (/usr/lib/systemd/system), which
dracut reliably sets on all versions. This matches how the ostree dracut
module has always handled this. The fix is unconditionally correct for
all dracut versions.
Assisted-by: OpenCode (Claude Sonnet 4.6)
Signed-off-by: Colin Walters <walters@verbum.org>
Linux kernel 7.0 and 7.1 introduced a requirement that all files in a composefs image carry fs-verity digests. bootc only applies verity to content objects, not every file, so erofs mounts fail with 'has no fs-verity digest' on these kernels. This is a kernel regression tracked upstream; 7.2+ is expected to restore the prior behavior. In provision-fetch.sh, detect kernel 7.0.x/7.1.x in the base image and downgrade to 6.19.10-300.fc44 from Koji before the image build runs. The downgrade uses --noscripts to prevent the kernel-core posttrans scriptlet from invoking kernel-install (which fails and pollutes /boot inside the container), then runs depmod manually and removes leftover module directories from the replaced kernel. This workaround should be removed once base images ship kernel 7.2+. Assisted-by: OpenCode (Claude Sonnet 4.6) Signed-off-by: Colin Walters <walters@verbum.org>
There was a problem hiding this comment.
Code Review
This pull request updates the initramfs module setup to use the systemd unit directory for target dependencies and introduces a temporary kernel downgrade in the provisioning script to address a composefs issue in kernel versions 7.0 and 7.1. Review feedback highlights potential issues in the downgrade logic, specifically regarding multi-version kernel detection and the need to explicitly remove the problematic kernel packages to ensure the downgraded version is correctly prioritized.
| # which calls rpm-ostree, and that fails inside a container build. | ||
| # We manually run depmod afterward since it's the only useful | ||
| # scriptlet the kernel packages would otherwise execute. | ||
| dnf -y install --allowerasing --setopt=tsflags=noscripts "${kernel_td}"/*.rpm |
There was a problem hiding this comment.
Using dnf install on an older kernel version will install it alongside the existing 7.x kernel rather than replacing it. Since the 7.x kernel has a higher version number, it will likely remain the default boot option. Deleting the module directory manually (lines 167-172) will leave the 7.x kernel in a broken state (missing modules) while still being the default. It is better to explicitly remove the 7.x kernel packages to ensure the 6.x kernel is preferred and the RPM database remains consistent.
| dnf -y install --allowerasing --setopt=tsflags=noscripts "${kernel_td}"/*.rpm | |
| dnf -y install --allowerasing --setopt=tsflags=noscripts "${kernel_td}"/*.rpm | |
| dnf -y remove --setopt=tsflags=noscripts "kernel*-7.[01]*" |
There was a problem hiding this comment.
Good thought Gemini, but we actually set installonlyn in our base image to turn off that dnf behavior.
|
Hm Not immediately sure what that's all about, I can run |
|
Trying to bump to the latest bcvk release to see if that magically fixes it. |
|
Well same issue with newer bcvk, although it occurs to me that we should probably be testing fedora-44 now in the upgrade matrix so let me try switching that out and see if it makes any difference as well (probably we should test both stable fedora releases but if we can get by with changing to fedora-44 for the moment that's progress). |
Really we should probably test both of these while they're stable Fedora versions, but currently CI is blocked on the f43 upgrade job being broken, and if switching to f44 unblocks things that's progress. Signed-off-by: John Eckersberg <jeckersb@redhat.com>
bae04c0 to
bb8e7dd
Compare
For fedora 44 we install kernel v6.19 ourselves and not run the postprocess scripts that would've generated the initramfs. This causes bcvk to fail with `No kernel found` So we explicitly regenerate the initramfs in Dockerfile.upgrade Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
|
Test Upgrade passes now |
|
Ugh I'm sorry I created a mess here because I somehow pushed some early agent-generated garbage instead of a later cleaned up iteration. (It's complicated, I'm traveling w/o my usual devenv local, plus various other compounding things). The root brokenness here is the |
Yes, we really do need to add at least our basic TMT tests as gating on Fedora packages.