Stock ignition configuration

[davidcassany]

This PR adds the --mode merge and --mode splitmerge in elemental3 customize. If mode merge or splitmerge is set Elemental will embed the Ignition configuration as an initrd extension. With this option the ignition configuration will be seen as base configuration from Ignition's PoV and allow to merge on top additional user configuration. Moreover, the configuration partition, if any at all, will be labeled with CATALYST instead of ignition if no <mnt>/ignition/config.ign file is present. merge mode keeps the rest of the configuration embedded in a configuration partition. splitmerge generates non ignition configuration in a configuration directory separate from the image.

This is handy in scenarios where the user configuration is provided by the platform instead of being embedded within the image itself. Consider cases such as deploying in cloud providers.

[davidcassany]

This PR is based on top of #522 and #523, because of that it is marked as draft. The diff will be way easier to read and review once #522 and #523 are part of the main branch.

[ipetrov117]

Thanks for the work on this @davidcassany! I left one suggestions that I would be interested to hear your thoughts on.

Apart from that, I hit an error when trying to test the changes. Below I tried to explain what I found, but the TL;DR is that it seems to be related to how we handle already defined initrd extensions during the installer's boot environment.

Error hit when doing ./elemental3ctl --debug install at install time:

INFO[0033] Installing kernel/initrd
INFO[0033] Reading OS Release
DEBU[0033] Concatenating extensions [/run/initramfs/live/Install/0-0-initrdExt.cpio] and initrd "/tmp/elemental_system158623787/@/.snapshots/1/snapshot/usr/lib/modules/6.12.0-160000.35-default/initrd"
ERRO[0033] Closing transaction due to a failure: installing bootloader: installing kernel+initrd: copying initrd '/tmp/elemental_system158623787/@/.snapshots/1/snapshot/usr/lib/modules/6.12.0-160000.35-default/initrd': stat /run/initramfs/live/Install/0-0-initrdExt.cpio: no such file or directory
[  243.306303][ T2088] EXT4-fs (sda3): unmounting filesystem e41514e2-03df-4660-adb3-cc64998c0971.

IIUC, this is happening because at install time we setup the recovery partition and run the addInstallationAssets boot config logic, which again attempts to copy the files from what is defined under initrdExtensions to /run/initramfs/live/Install/<index>-<entry-as-seen-in-initrdExtensions>. However, because the Deployment object at install time is populated from the /run/initramfs/live/Install/install.yaml file, which is already defined like so:

...
bootloader:
    ...
    initrdExtensions:
        - /run/initramfs/live/Install/0-initrdExt.cpio

the function adds an extra 0 index to the 0-initrdExt.cpio extension, which produces an invalid name that makes the underlying ConcatFiles function to fail with the mentioned error.

Please let me know whether I am doing something wrong, both when customising the image and operating in the installer boot environment, I am using an elemental3ctl binary built with this PR's changes.

[davidcassany]

Apart from that, I hit an error when trying to test the changes. Below I tried to explain what I found, but the TL;DR is that it seems to be related to how we handle already defined initrd extensions during the installer's boot environment.

Oh damn, yes I under estimated the change to rename files with a prefix to prevent overlaps, this logic gets called twice and causes the glitch, my bad. I am looking at it.

[davidcassany]

@ipetrov117 the regression seen on ISO installation is fixed. Moreover I also extended the mode flag with two additional modes merge and splitmerge. This way the current behavior remains unchanged and it adds some more flexibility on how to define ignition configuration. We can follow up on a UX discussion what and how we want to expose base configuration to the user.

[ipetrov117]

@davidcassany thanks, this looks great!

[davidcassany]

As discussed I changed the implementation to always set ignition configuration as stock base configuration. So no further modes have been applied and two existing ones changed their behavior to always embed the ignition configuration into the initrd. This allows to extend and/or overwrite ignition configuration at run time by merging the user configuration on top.