Drop the ext.config.disks.boot-partition-space denylist entry based on the resolution tracked in coreos/fedora-coreos-tracker#2239. The issue is no longer expected to require this test to remain snoozed.
Explain the production-stream update path, target-stream example, and architecture
requirements to make the extended upgrade test easier to run and debug.
Those labels are required to comply with Red Hat Enterprise Contract
(Conforma) policy downstream.
They are not mandatory for Fedora though be we add values anyway.
Initally, as those labels are for compliance, I wanted to set them in
the Tekton task prepare-build-context but then, they would not be tied
to the repo which is the source of truth. The alternative solution
was to set them in the tekton pipeline in r-c-c, but then local and
Konflux build would have a different result.
With that solution we keep consistencty between f-c-c and r-c-c, and
the same result between a local or Konflux build.
Dracut 111 breaks our CI due to a known bug. This bug has been fixed
in Dracut 112, but not RPM has yet been released.
While we wait for Dracut 112 RPM to be release / for the fix to be
backported to Dracut 111, we will manually patch the file so that we
dont need to keep Dracut 109 pinned for too long.
See: https://github.com/coreos/fedora-coreos-tracker/issues/2206
coreos-installer v0.27.0 is needed for these tests to pass on rawhide.
That version embeds NM keyfiles into the installed initramfs instead of
writing to /boot, which is required since fedora-coreos-config commit
7bed92f dropped the /boot network config path for F46+.
Track: https://github.com/coreos/fedora-coreos-tracker/issues/2235
- coreos-installer now embeds network config in the initramfs
instead of writing to /boot/coreos-firstboot-network. When a
system is provisioned with an older coreos-installer but boots
a newer image, the network config is stranded in /boot and
never applied — breaking network-dependent boot paths like iSCSI.
- Add a three-layer backward compatibility mechanism:
1. Initramfs rescue service (coreos-rescue-misplaced-network):
if no config exists in /etc/coreos-firstboot-network, mount
/boot and copy any legacy config found there so that the
existing coreos-copy-firstboot-network.service can apply it.
This is the active fix — it recovers the stranded config and
allows boot to succeed.
2. Dracut emergency hook (coreos-warn-misplaced-network.sh):
on iSCSI systems, /boot lives on a network device — but the
network config needed to reach it is stranded inside /boot
itself, so the rescue service cannot help. When this
chicken-and-egg problem causes the system to drop to an
emergency shell, this hook explains the situation and advises
re-installing with a newer coreos-installer.
3. Real-root warning service (coreos-warn-misplaced-network):
runs after boot has already succeeded (thanks to the rescue
service above). It does not fix anything — it warns
that legacy config was found in /boot, prompting
the user to re-install with a newer coreos-installer so
future boots do not depend on the rescue path. If /boot is
not mounted at all, it warns that this may itself be a
symptom of missing network config.
- We may drop it in the feature, since there is a
cost of keeping checking it
- See https://github.com/coreos/coreos-installer/issues/1758
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
- Drop the Before=dracut-initqueue.service systemd
unit ordering workaround in coreos-copy-firstboot-network.service.
- This ordering constraint was marked as a
compatibility fallback requiring dracut 054+.
Since both RHCOS (dracut 107) and FCOS (dracut
108) are well past this threshold, the ordering is
no longer necessary.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
/boot
- coreos-installer now writes network config files
directly to /etc/coreos-firstboot-network instead of /boot
(see coreos/coreos-installer#1765).
- Remove the /boot mount and the live-vs-diskful from
coreos-copy-firstboot-network, and drop the boot-device
dependency from the systemd unit.
- https://github.com/coreos/coreos-installer/issues/1758
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
systemd >= 262 (F45/F46) enables the new IMDS subsystem (ENABLE_IMDS). On
cloud guests systemd-imds-generator pulls in systemd-imds-early-network.service,
which runs `systemd-imdsd --setup-network` in the init_t domain. SELinux denies
it writing net_conf_t (/run/systemd/network/85-imds-early.network) and
systemd_resolved_var_run_t, so the unit fails and trips the boot health check,
causing every kola test to fail on next/rawhide across Azure, AWS and GCP.
FCOS gets metadata via afterburn and configures networking via NetworkManager,
so it does not need systemd's IMDS pre-networking. Mask the subsystem until (if
ever) it is wanted and selinux-policy grows rules for it.
https://github.com/coreos/fedora-coreos-tracker/issues/2232
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add `get_lockfile_dir()` helper function that looks for lockfiles in
`lockfiles/${stream}/` first, then falls back to the srcdir root.
This allows rhel-coreos-config to maintain lockfiles per stream in main
branch instead of having separate branches.
The `get_locked_nevras()` function now accepts a `stream` parameter
and uses the new helper to determine the lockfile directory.
