As part of an effort to test more on non-CoreOS bootable
container images we'd like a cross architecture way to
expose systemd credentials into a VM. This commit adds a
new import-virtiofs-systemd-credentials.service that runs
in the initramfs and will copy credentials exposed via the
io.systemd.credentials virtiofs tag into the /run/credentials/@initrd
directory, which will then get imported by systemd itself.
Related to https://github.com/systemd/systemd/issues/29175 upstream.
Assisted-by: <anthropic/claude-opus-4.6>
fcos.upgrade.basic/upgrade-from-previous consistently fails on
aarch64 GCP instances with SSH reboot timeout errors (~23s). The
same build passes on AWS aarch64 and GCP x86_64. Snoozed until
2026-07-10.
Tracker: https://github.com/coreos/fedora-coreos-tracker/issues/2174
This allows the final directory name of the overlay dir
to determine the ordering the overlays are applied in.
A file in 03-core/etc/foo.d/file would override a file
in 02-core/etc/foo.d/file.
Here's how that ends of looking when building against
rhel-9.8 CoreOS (i.e. https://github.com/coreos/rhel-coreos-config/pull/276)
```
--add-dir=/src/fedora-coreos-config/overlay.d/05core
--add-dir=/src/overlay.d/05rhcos
--add-dir=/src/overlay.d/06gcp-routes
--add-dir=/src/fedora-coreos-config/overlay.d/08nouveau
--add-dir=/src/overlay.d/15rhcos-journald-backcompat
--add-dir=/src/overlay.d/15rhcos-networkmanager-dispatcher
--add-dir=/src/overlay.d/15rhcos-networkmanager-plugin-order
--add-dir=/src/overlay.d/15rhcos-tuned-bits
--add-dir=/src/fedora-coreos-config/overlay.d/20platform-chrony
--add-dir=/src/overlay.d/21dhcp-chrony
--add-dir=/src/overlay.d/30gcp-udev-rules
--add-dir=/src/fedora-coreos-config/overlay.d/30lvmdevices
--add-dir=/src/overlay.d/30rhcos-nvme-compat-udev
--add-dir=/src/fedora-coreos-config/overlay.d/40import-virtiofs-systemd-credentials
```
The test was failing on ppc64le and s390x with:
+ grep -iq 'ConditionArchitecture=!s390x was not met'
+ fatal 'bootloader-update.service was not skipped for s390x'
This is because bootupd now uses a preset file (10-ppcle-s390x-disable.conf)
to disable the service on ppc64le/s390x, which makes the service 'inactive'
instead of showing a ConditionArchitecture message.
Fix by using 'systemctl is-active' and checking for 'inactive' status.
Also refactor to reduce code duplication with helper functions.
This will allow us to define them here so we don't have to redefine them
downstream. As long as shared-el.yaml gets included downstream the rest
of these will get included.
Previously ostree-layers entries strings had to start with '/overlay'
and it was hardcoded to look into the overlay.d/ directory for them.
Rather than this let's just have the strings in the list be the actual
directory the override resides in.
Also here we rename a bunch of variables in build-rootfs to be add_dirs
instead of overlays, because the argument to bootc-base-imagectl is
--add-dir.
Make the comment at the top more accurate and add some debug logs
for the arguemnts in the args file that are passed in so we can see
what's happening under the hood during a build.
The buildah sanitize feature [1] scopes path-based image transports to
the build context directory. Instead of using absolute paths, use
a named image.
Closes: #4228
[1]
705ba3b9b6
New versions of containers-common no longer install policy.json in
/etc/containers. Because of this, when coreos-containers-policy.conf
creates a bind mount, systemd will first create an empty file
/etc/containers/policy.json. After that, tools like podman and skopeo
will error out when they try to parse that empty json file.
To fix this, copy /usr/share/containers/policy.json to
/etc/containers/policy.json.
Closes: #4215
This should help diagnose issues which aren't just network flakes. The
redirect was originally from e5b3bcd, but it's no longer required since
0d7d716.
With the new OSTree tarball the upgrades move so fast that an
upgrade can happen and start a reboot before the kola ext test
script even starts running, which causes the test framework to
get out of sorts.
Let's just disable zincati on the first run and start it manually
on each boot.
The OSTree repo in Fedora can be slow and might go away one day.
Since we know exactly the path updates are going to take let's
just download pre-built tarballs with an OSTree repo inside
that has exactly the contents that this upgrade will need.
The tarballs for this purpose can be created with the script in [1].
You can download the tarball into the external data directory before
running the test to have it exist and be used:
```
curl -o src/config/tests/kola/upgrade/extended/data/ostree-repo.tar \
https://fcos-upgrade-test-fixtures.s3.us-east-1.amazonaws.com/ostree-repo-testing-x86_64-starting-f34.tar
cosa buildfetch --artifact=qemu --decompress --build=34.20210427.2.0
cosa kola run --build=34.20210427.2.0 --tag extended-upgrade
rm src/config/tests/kola/upgrade/extended/data/ostree-repo.tar
```
[1] https://github.com/coreos/fedora-coreos-releng-automation/pull/231
This code only runs when we're at our final destination
and our final destination for upgrade tests today is F44
or F45 so we can safely drop this exception code.
