Copy the latest multi-arch lockfiles and overrides from next-devel at f91914d6. Update the F45 bootc builder image while preserving the testing-devel stream identity.
Instead of programatically estimating the size of the root partition
we hard-code the value in the partition table and add a test to
verify that we always have at least 25% free space available.
I tried to replicate COSA logic in [1] to estimate the required root
partition size but since we don't have the ostree commit during
the container build it's still a big guesstimate: we have to
account for the XFS block size and how each metadata file will eat a
full block.
So instead of a half-measure / half guess we use a full hardcoded
approach with an accompagnying test.
[1] https://github.com/coreos/fedora-coreos-config/pull/4259
This add a kernel-argument switch to make ignition-ostree-growfs.service
a no-op. The main goal of this is to enable a test to control if we are
provisionning enough space on the root partition by default, but is
generally useful.
- Check for the deliberate sentinel file. When
present, the /boot placement was intentional
(e.g.assisted-installer iSCSI flow) and
we should not flag it as a misplaced config.
- This is a temporary workaround until a final
solution for image replacement is in place.
See:
https://github.com/openshift/assisted-installer/pull/2501
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
In the previous commit we added systemd-inhibit to refchanged.service
to ensure autopkgtest-reboot-prepare finishes and receives a reboot
ack before rebooting.
However, refchanged.path remains active after refchanged.service exits.
When ostree finalizes the deployment, systemd receives additional
inotify CLOSE events and triggers refchanged.service a second time:
[ 87.705972] inotify-debug: === inotify PathChanged event triggered on /ostree/deploy at 2026-10-30T10:00:02,501171636+00:00 ===
[ 88.008602] systemd[1]: Started refchanged.path - /usr/bin/systemd-inhibit "--why=Wait for autopkgtest-reboot-prepare to finish" bash /tmp/autopkgtest-reboot-prepare 40.20240701.3.0.
[ 88.270891] systemd[1]: Started refchanged.service - /usr/bin/systemd-inhibit "--why=Wait for autopkgtest-reboot-prepare to finish" bash /tmp/autopkgtest-reboot-prepare 40.20240701.3.0.
...
[ 94.813483] inotify-debug: === inotify PathChanged event triggered on /ostree/deploy at 2026-10-30T10:00:09,609520834+00:00 ===
[ 94.911221] systemd[1]: Started refchanged.service - /usr/bin/systemd-inhibit "--why=Wait for autopkgtest-reboot-prepare to finish" bash /tmp/autopkgtest-reboot-prepare 40.20240701.3.0.
[ 94.920249] systemd-inhibit[2560]: Failed to inhibit: The operation inhibition has been requested for is already running
On the second execution, systemd-inhibit fails with:
systemd-inhibit: Failed to inhibit: The operation inhibition has been requested for is already running
systemd[1]: refchanged.service: Failed with result 'exit-code'.
This happens because the shutdown/reboot process is already underway
from the first run.
Set RemainAfterExit=yes on refchanged.service so systemd considers
the service active after completion and does not trigger it a
second time.
We've seen issues where tests fail because of a race condition
where the reboot occurs prior to the kola side of the reboot
request/ack happening.
We have the refchanged.service that will run
`bash /tmp/autopkgtest-reboot-prepare $version` and that basically
will request a reboot via /run/kolet-reboot (where main kolet
is listening, which will then talk to remote kola) and then wait
for an ack via /run/kolet-reboot-ack.
The race condition we've seen is where the system reboots via
zincati too quickly and the reboot ack never had a chance to
come through. The attempt to send the ack by kola by doing a
echo > /run/kolet-reboot-ack via m.SSH in harness.go then fails
because the SSH doesn't succeed, which leads to a failed test.
Using systemd-inhibit here means we should wait for the ack to
come through before allowing the system to go down for a reboot
and hopefully we'll mitigate the race condition.
Was reduced to 50 in 976dcac1 when switching to a local ostree tarball,
but network retries on transient errors can push upgrade chains past 50
minutes:
2026-10-28T09:22:47Z kola: dropping to shell: kolet failed: kolet run-test-unit failed: : context canceled:
Services generated from a volume quadlet no longer have
RemainAfterExit=yes by default[1], so the is_service_active check will
fail with new versions of podman. Instead we can check that it ran
successfully.
[1] https://github.com/podman-container-tools/podman/pull/29375
Ignition versions before 2.14 do not remove pre-existing enablement
symlinks for units configured with `enabled: false`.[1] On older upgrades,
this leaves Zincati enabled across the upgrade chain, where it can stage
an update and reboot before the external test regains control.
Disable and stop Zincati before setup on every invocation. The test
continues to start it explicitly once it is ready to monitor the update.
[1]: https://github.com/coreos/ignition/releases/tag/v2.14.0
Assisted-by: <openai/gpt-5.6-sol>
- Add RHCOS_STREAM_TO_NUM, starting with the Nvidia
stream, to map RHCOS build IDs to stream numbers
based on the layers being built.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
- The coreos-gpt-setup.service triggers sgdisk on firstboot to regenerate
the GPT disk GUID. This causes a transient partition table re-read that
momentarily removes the /dev/disk/by-label/boot symlink.
ignition-ostree-uuid-boot.service (tune2fs) does the same.
- Because coreos-rescue-misplaced-network.service depends on
ConditionPathExists=/dev/disk/by-label/boot, it can accidentally be
skipped if the condition evaluates exactly while the symlink is missing.
- Fix this by explicitly ordering the rescue service
Before=coreos-gpt-setup.service, so the condition is evaluated while
the symlink is still stable. Since coreos-gpt-setup already orders
before ignition-ostree-uuid-boot, so it covers both.
- Also add Before=coreos-boot-edit.service to guarantee the network
config is copied before boot-edit removes /boot/coreos-firstboot-network.
Fixes: OCPBUGS-132171
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
build-args.conf gained a COMPONENT line, set per-stream like STREAM and
DESCRIPTION (e.g. fedora-coreos-testing-devel vs fedora-coreos-testing),
so we need to ignore COMPONENT as well.
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.
