Elemental boot process

[davidcassany]

We currently have a single elemental dracut module that handles all elemental specific logic required within the initramfs. I believe this is a wrong approach because we should have devoted dracut modules for each of the different independent features we need in initramfs phase.

For instance the logic around how the ephemeral and persistent paths are set should be independent on how and when certain cloud-init stages are executed. Cloud-init services should be completely unrelated to the rootfs layout.

For that I think we require three different dracut modules:

elemental-sysroot

• sysroot.mount generator (requires run_elemental_state.mount or run_elemental_recovery.mount)
• run_elemental_state.mount or run_elemental_recovery.mount generator (after and wants initqueue)
• cmd_line parser adds a wait for initqueue on state or recovery device
• all the logic required by the initrd-root-fs.target

elemental-setup

• includes generator for /oem mount (so elemental-setup-rootfs.service can actually pull configurations from an external device or remote data in very early stages)
• includes elemental-setup-rootfs.service (required by initrd-root-fs.target and requires sysroot.mount) and setup-initramfs (after initrds-fs.target)
• this dracut module could be part of the current elemental-setup feature

elemental-rootfs

• service elemental-rootfs (after initrd-root-fs.target and before before initrd-fs.target)
• in just applies the mounts for the defined ephemeral and persistent paths.

Elemental boot proces:

1. Some systemd generators

   • sysroot generator -> defines the mount units for sysroot and the state|recovery partition [part of elemental-sysroot]
   • oem generator -> defines the mount for /oem in initrd and its timeout [part of elemental-setup]

2. Cmd line parse to include state|recovery wait in initqueue [part of elemental-sysroot]

3. Basic target (initqueue ended with required devices found)

4. Mount state|recovery, sysroot and initrd oem

   • state|recovery and sysroot mounts required by initrd-root-fs.target [part of elemental-sysroot]
   • oem mount, wanted by initrd-root-fs.target [part of elemental-setup]

5. setup-rootfs.service [part of elemental-setup]

   • requires and after sysroot
   • wants and after oem mount
   • required by initrd-root-fs.target
   • umounts oem

6. initrd-root-fs.target is reached

7. service elemental-rootfs [part of elemental-rootfs]

   • requires and after initrd-root-fs.target
   • required by initrd-fs.target

8. initrd-fs.target

9. service setup-initramfs

   • requires and after initrd-fs.target
   • required by initrd.target

10. initrd.target is reached

This is not a change in the current boot process it is a change on how it is provided and how responsibilities are split across different logic blocks. Shouldn't be hard to implement and the result would help to better outline which are the features that elemental-toolkit provides and make them opt-in.

[frelon]

Great writeup! I will try to implement some these changes in #1837 so we get closer to this state!