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>
- 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>
- 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>
The upstream sshd@.service overrides AuthorizedKeysFile in the ExecStart
command, which excludes .ssh/authorized_keys.d/* where Ignition and
Afterburn place SSH keys. This breaks SSH logins for systems using
socket-activated sshd.
Add this overlay as a workaround to dynamically override ExecStart while
a better solution is discussed upstream.
In the case that we don't take down networking we can get into
a weird situation where NetworkManager will detect that the NICs
are already configured and "regnerate" NM connection files in
/run/, but sometimes they miss some information (like DNS) [1].
Let's just skip the cleanup of /run/ files here if we didn't
actually take down networking because of iSCSI.
[1] https://github.com/coreos/fedora-coreos-tracker/issues/2196
Add the partition names to the `disk.yaml` image-builder configuration
file. The partitions were correctly labelled at the filesystem level but
were missing names from the GPT parition table.
This was causing some issues with reprovisionning. Let's make sure the
resulting partition table is identical to what we have when building
disk-images with COSA.
See how partitions names are set in COSA at the GPT table : a2b4dd6c90/src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml (L65)
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>
bootc-image-builder needs a disk partition table definition at
/usr/lib/image-builder/bootc/disk.yaml to produce disk images. Each
architecture has a different partition layout (e.g. BIOS boot on x86_64,
PReP on ppc64le, no boot partition on s390x), so the correct file must
be selected at build time.
This follows the same injection pattern already used for platforms.json
and image.json: build-rootfs links the correct partitioncorrect partition
table from the disk-image overlay.
Authored-by: Opencode.ai claude-opus-4-6@default
This is actually overwritten by image-builder's
disk.yaml partition table definition but is still required
This can be dropped when https://github.com/osbuild/images/issues/2380
is fixed.
Instead of hard-coding the ostree stateroot in an overlay we dynamically
create the bootc install config file using the NAME variable sourced
from the Containerfile ARG, now propagated to postprocess scripts via
the previous commit.
Authored-by: Opencode.ai <claude-opus-4-6>
There are a few options that we are hard-coding in COSA right now, but
with [1] we can pull them from the OCI container, so let's do that
instead and make the container the canonical source of truth.
Also rework this overlay a bit in two files : the firstboot related
options and the one related to the ostree repository.
[1] 364ccaebeb
Introduce a new overlay to ship configuration files for bootc and
image-builder. These file are sourced from the container during
`bootc install to-filesystem`.
We can also use this later to ship other bits as we make the container
more and more the source of truth, e.g. the partition table definition.
This is prep work for [1]
[1] https://github.com/coreos/fedora-coreos-tracker/issues/1827
See also https://github.com/coreos/coreos-assembler/pull/4224
The systemd-firstboot.service is a static unit (no [Install] section)
which means you can't just enable or disable it as one would typically
do so IIUC the preset disablement does nothing anyway.
The systemd-firstboot.service.d/fcos-disable.conf override also seems to
be unneeded because the only thing trying to pull it in is disabled at
the bootc level anyway [1].
Maybe let's just remove these workarounds because it seems like they
aren't needed.
[1] 9f9824c9a4/minimal/manifest.yaml (L18)
At some point the socket started getting enabled by default [1], which means
systemd-oomd.service was running. Let's disable the socket too.
[1] b056f04a01/f/90-default.preset (_15)
We been progressively exploring sysexts more [1] and the service today
won't actually run uness /etc/extensions, /run/extensions, or /var/lib/extensions
has files.
```
[core@cosa-devsh ~]$ systemctl status systemd-sysext.service
○ systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/
Loaded: loaded (/usr/lib/systemd/system/systemd-sysext.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: inactive (dead)
Condition: start condition unmet at Mon 2026-04-20 19:23:40 UTC; 17s ago
├─ ConditionDirectoryNotEmpty=|/etc/extensions was not met
├─ ConditionDirectoryNotEmpty=|/run/extensions was not met
└─ ConditionDirectoryNotEmpty=|/var/lib/extensions was not met
Docs: man:systemd-sysext.service(8)
```
Let's remove the preset disablement here.
[1] https://fedora-sysexts.github.io/fedora/
Since we don't ship it anyway this will have no effect other than
preventing a harmess warning message:
```
dracut[I]: Could not find 'strip'. Not stripping the initramfs.
```
I think keeping this config and spending cycles in the future to figure
out if it is still useful is more harmful than it's worth.
As a side note the bootc base images don't have this config. If we did
decide it was important enough in the future to re-add this I would argue
the config should get added there, rather than re-added here.
bootup is now using a transient systemd service and no longer use the
socket unit.
The actual service unit trigerring the updates is enabled in the Fedora
bootc image.
See: https://github.com/coreos/bootupd/issues/551
The azure sriov unmanaged rules were added upstream to azure-vm-utils
[1] and we're shipping that package so we should be good to drop this
overlay now.
I confirmed that the rules are included in the initramfs, so we should
be covered there:
```
[core@cosa-devsh ~]$ rpm -q azure-vm-utils
azure-vm-utils-0.7.0-1.fc43.x86_64
[core@cosa-devsh ~]$ sudo lsinitrd | grep 10-azure-unmanaged-sriov.rules
-rw-r--r-- 1 root root 640 Jan 1 1970 usr/lib/udev/rules.d/10-azure-unmanaged-sriov.rules
```
[1] https://github.com/Azure/azure-vm-utils/pull/41
Thank you Dusty for pointing out the root cause in
https://github.com/coreos/fedora-coreos-config/pull/3862#issuecomment-3467947591
For centos stream and rhcos, the tests that want to use
"/dev/disk/by-id/coreos-boot-disk" failed with
```
ignition[728]: disks: createPartitions: op(1): [failed] waiting
for devices [/dev/disk/by-id/coreos-boot-disk]: device unit
dev-disk-by\x2did-coreos\x2dboot\x2ddisk.device timeout
```
e.g. `ext.config.shared.ignition.stable-boot`
Detail logs:
`/usr/lib/udev/coreos-disk-contains-partition-name: line 28: sfdisk: command not found`
