I want to install coreOS on redundant encrypted disks. Since coreOS integrates heavily with butane/ignition i tried Examples | Butane
I create an unattended iso via coreos-installer iso customize --live-karg-append="ignition.config.url=https://example.com/config.ign" -o ./ignition_coreOS.iso fedora-coreos-42.20250929.3.0-live-iso.x86_64.iso then i use dd to write it to a complete usb block device. I plug the thumb drive to a blank bare metal system with 2 sata drives.
As long as my Butane file does not contain a boot_device: section the setup installs on the device on the first sata port. i can login via ssh with the configured values in my butane.
When i add boot_device: mirror with 2 devices the partitions are setup as expected and i can login via the configured ssh credentials, but the filesystems for /boot and ESP are not mounted. Accordingly they do not contain the files to actually boot the system. So rebooting results in no available boot option.
i tried mounting the ESP & boot partitions and copied the contents of /boot and /boot/efi respectively. That results in a grub emergency shell on reboot. I could not salvage further information from this attempt.
When i add boot_device: luks: the systems drops into an emergency shell. The reason is ignition-disks.service timing out. i collected the logs from these attempts. i will look through them and paste the relevant data here.
I am not confident in debugging this type of problem and completely new to butane/ignition. So feel free to ask for any specific information.
butane attempts
With every deployment, working or not, i used the following configuration:
All the yaml was converted into ignition JSON via podman run --rm --interactive --security-opt label=disable quay.io/coreos/butane:release --strict < butane.file > ignition.file && podman run --quiet --pull=always --rm -i quay.io/coreos/ignition-validate:release - < ignition.file
I also took the examples from butane/docs/examples.md at main · coreos/butane · GitHub and the mirror section below that with minimal derivation, just substituting the disks and architecture if needed. This showed the same behavior as my own butane config.
Thanks for reading and hopefully your clever tip that will make this go away.
It’s expected that the ESP isn’t mounted, but not /boot. For the ESP there are technically two copies here (they aren’t actually in a RAID) so manually messing around in there wouldn’t be good. bootupd should handle bootloader updates across both copies. i.e. it will mount them both and put all the right stuff in there and then unmount them.
I wouldn’t expect that. If you can reproduce please open a bug with all the details (including logs).
Did you try this bare metal or in a hypervisor of sorts? For me it only happens on bare metal.
Should this happen before the system drops into loginshell?
I have used your posted Butane to test. Only substituting ssh pubkey.
the flow for me is: UEFI boot ignition ISO > access via igniton credentials is possible >
ESP, boot and root partition are empty
# for i in esp-1 esp-2 boot root; do \
umount /mnt/ 2>/dev/null \
mount /dev/disk/by-label/$i /mnt/ &&\
echo "$i" && ls -al /mnt/
done
esp-1
total 20
drwxr-xr-x. 2 root root 16384 Jan 1 1970 .
drwxr-xr-x. 24 root root 4096 Oct 23 20:08 ..
esp-2
total 20
drwxr-xr-x. 2 root root 16384 Jan 1 1970 .
drwxr-xr-x. 24 root root 4096 Oct 23 20:08 ..
boot
total 17
drwxr-xr-x 3 root root 1024 Oct 23 20:07 .
drwxr-xr-x. 24 root root 4096 Oct 23 20:08 ..
drwx------ 2 root root 12288 Oct 23 20:07 lost+found
root
total 4
drwxr-xr-x 2 root root 6 Oct 23 20:07 .
drwxr-xr-x. 24 root root 4096 Oct 23 20:08 ..
VM. I rarely have time or hardware to test things on bare metal, but 99% of the time “bare metal” problems can be reproduced in a VM.
hmm. This log is a little concerning to me. I think somehow you are mixing two things.
The Ignition partitioning should happen on the first boot (i.e. after the install has happened and the system has been rebooted). In your log the partitioning is happening during a “live” boot:
Oct 23 22:55:15 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(1c): op(22): op(28): [finished] waiting for triggered uevent
Oct 23 22:55:15 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(1c): op(22): [finished] waiting for triggered uevent
Oct 23 22:55:16 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(1c): [finished] creating "ext4" filesystem on "/run/ignition/dev_aliases/dev/md/md-boot"
Oct 23 22:55:16 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(29): [started] waiting for triggered uevent
Oct 23 22:55:16 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(29): executing: "udevadm" "trigger" "--settle" "/dev/md127"
Oct 23 22:55:16 setHostname.local ignition[767]: disks: createFilesystems: op(1b): op(29): [finished] waiting for triggered uevent
Oct 23 22:55:17 setHostname.local ignition[767]: disks: createFilesystems: op(1b): [finished] creating "xfs" filesystem on "/run/ignition/dev_aliases/dev/mapper/root"
Oct 23 22:55:17 setHostname.local ignition[767]: disks: createFilesystems: op(2a): [started] waiting for triggered uevent
Oct 23 22:55:17 setHostname.local ignition[767]: disks: createFilesystems: op(2a): executing: "udevadm" "trigger" "--settle" "/dev/dm-0"
Oct 23 22:55:17 setHostname.local ignition[767]: disks: createFilesystems: op(2a): [finished] waiting for triggered uevent
Oct 23 22:55:17 setHostname.local ignition[767]: disks: disks passed
Oct 23 22:55:17 setHostname.local ignition[767]: Ignition finished successfully
Oct 23 22:55:17 setHostname.local systemd[1]: Finished ignition-disks.service - Ignition (disks).
Oct 23 22:55:17 setHostname.local systemd[1]: Reached target initrd-root-device.target - Initrd Root Device.
Oct 23 22:55:17 setHostname.local systemd[1]: Mounting run-media-iso.mount - /run/media/iso...
So your filesystems got all set up right, but yeah they are empty because this is a live ISO boot (as evidenced by the Mounting run-media-iso.mount log statement).
NOTE: Live ISO boots are typically meant for installs (or you can run “live” too, but configuring the root filesystem in that case would be pointless).
This means there’s nothing that copied out the root filesystem and will copy it back in because:
Oct 23 22:54:49 setHostname.local systemd[1]: ignition-ostree-transposefs-detect.service - Ignition OSTree: Detect Partition Transposition was skipped because of an unmet condition check (ConditionKernelCommandLine=ostree).
TL;DR I think your Ignition config with disk partitioning info is running during the install boot and that’s not what you want.
