Support for reconfiguring the root storage

[ajeddeloh]

FCOS will have a static, server-side generated initramfs. This means the initramfs needs to know how to find the root filesystem to mount it, including if that means starting RAID devices. However, we do NOT want to start other raid devices (unless Ignition is starting them as part of the creation process) since users might be writing out configuration to things like /etc/mdadm.conf that they want to use.

On CL we require that RAIDed devices be partitions with the a special GPT partition type guid and have a udev rule to start only those.

For FCOS I can see two options:

• Do something similar to what CL did. This has the limitation of being unable to use whole disks for raid and requires partition tables where they would not otherwise be needed.
• Have some sort of file that gets written out to /boot which is a "rootmap". This would describe the "path to root" including what services like mdadm need to be started. Ignition could generate this if we include a way of flagging partitions/RAIDs as "containing root" or it could be user written. If it is user written we should unmount root after Ignition files/umount and then let whatever tooling reads it mount the root itself to ensure the first boot is not "special" in any way.

[martinezjavier]

Thanks. I had come across the zipl issue, but hadn't realized ppc64le would also be an issue. Hmm, Petitboot runs in its own complete Linux environment, right? Could it concatenate the initrds itself and pass that to kexec?

Yes, I also thought that this is how it could be handled by Petitboot. And in my opinion is what zipl should do as well, since the constraint of only supporting a single initrd seems rather artificial to me.

After all the the zipl user-space tool needs to be executeed anyways to update the zipl entries if any of the images changed, so I don't see why it couldn't just do the concatenation before writing a single initrd.