A different approach to prepare and configure the initramfs... Agreeable?

Ask Fedora
,
1

A more handcrafted sculpted initramfs, part of the particular kernel and container image (with bootc or so supporting preparing one within a Containerfile),

with more careful testing, more minimal, no tangled initqueues, just systemd, unit files, related tools… minimal, bulletproof, extensible at boot.

What it 1st does is to load the bare minimum kernel drivers to access the ESP/BLS partition via the kernel cmdline, then overlay a “companion” or “extension” with more info, like:

  • The root partition
  • Sequence of LVM activation, LUKS unlocking, whatnot
  • Specific extra firmware, modules, etc… as needed for that specific hardware
  • The relevant files for non-default hardware, like a bluetooth keyboard and mouse (in initramfs!!!), with the connection details etc..
  • The chosen plymouth theme, config, etc…
  • An advanced user wants another fancy password prompt? He just drops his files and scripts in some appropriate location.

Signed with a private key (hidden), the public certificate alongside it in the ESP/BLS, the initrd can verify and then decide what to do.

As usual the final unit to start in the initrd shall be systemctl switch-root to move to the root.

As a more carefully prepared one rather than “generated on demand”, many things will be more fixed, yet more flexible, the booting there will be more straightforward with more optimized routines, just systemd unit files, around 80% of the binaries required would be of systemd only, besides cryptsetup and so on.

systemd-udevd etc… would continue running through the sysroot, started in the initramfs.

The kernel cmdline will be empty, maybe a really small set of knobs… The config files take care of almost all things.

(For “systemd.unit=xyz.target” or similar) Maybe a keyboard shortcut in the initrd? OR in advanced scenarios a Plymouth prompt? Do such cases really appear so often? AND if the kargs are empty, they could be safely be used as boot-time knobs for non-sensitive uses

So how’s the idea?

Repository: MyFedoraContrib / Modular and streamlined initramfs · GitLab

2

I’m not entirely sure if the topic belongs in this particular category and all the tags, nor do I understand all the suggestions here.

Since the questions are related to bootable containers (which are fully customizable, including regenerating the initramfs during container build), I would suggest trying to build a derived container image to test the changes. If this doesn’t work as expected, another option would be to try building a base bootable container image from scratch.

3

Kindly suggest otherwise. I am not sure

My idea is about changing the concept of “generating” the initramfs itself.

Let me explain: (basic steps excluding things like logging)

  • The kernel loads initramfs-1, with the binaries and basic systemd unit files
  • Basic core services like systemd-udevd are started.
  • The BLS partition is mounted (discovery mechanism yet-undecided) to get the next initramfs
  • The initramfs-2 cpio image is checked against the public key next to it, proceeds if signature is valid (failure case yet-undecided), then unpacked unto / along with the 1st.
  • It brings the configuration files and extra systemd units to proceed further, including:
    • What else to mount on the rootfs? (Allows /etc to be a separate partition)
    • The most complex of stacks the rootfs is hidden on can be traversed (LVM, LUKS, bcache, whatnot combined) with specific configuration meant for that.
    • The bluetooth config for the keyboard and mouse to automatically connect (before the LUKS prompt to the rootfs). (In this case the binary too… as bluetooth isn’t common enough)
    • The plymouth theme
    • Out-of-the-box scripts by an advanced user (AT USER’S OWN RISK)
    • And quite a few other things usually reserved for the kargs
  • And since the core initramfs is not “regenerated every so”, it can be “crafted” using exclusively systemd unit files, and a negligible no. of scripts here and there, to work without issues…
  • No tangling crazy initqueues, grappling with huge kargs lists and so on.
  • So it will be small despite being packed… with around 80-90% of all requirements now satisfied by systemd alone..
  • Minor modifications like including an extra mount to be done in the initramfs itself, or supporting resume from hibernation, is just added in form of unit files or negligible scripts into the 2nd initramfs, which can be “generated every so on demand”.

This is mainly for Atomic distros where you can use a reproducible server-side initrd or build your own, and the latter breaks many immutability guarantees…

4
  1. System boots upto kernel
  2. Kernel loads an initramfs supplied by the UKI/bootloader as usual.
  3. The initramfs works as usual… except it doesn’t. PID-1 is systemd. ONLY systemd units guide the order and function.
  4. It just starts basic services like systemd-udevd required for basic function.
  5. It then mounts the BLS boot (xbootldr) partition where the “secondary” initrds are stored. (with the primary one and kernel maybe)
  6. It verifies that the initramfs-2 is signed correctly, against the accompanying public key. (or checksum-verification otherwise)
  7. It extracts that unto itself (to /) immediately followed by a systemctl daemon-reload
  8. The new freshly delivered systemd units hook into the boot chain.
  9. Plymouth is started, miscellaneous other similar tasks.
  10. LVM, LUKS, etc… are unlocked in order until the rootfs is mounted onto /sysroot.
  11. Other important mounts as needed, like /sysroot/etc.
  12. Helper setup necessary, like ostree-initrd-helper preparing the correct deployment.
  13. The final unit to run will execute systemctl switch_root /sysroot.

And the main OS continues

8

I think, but I’m not sure, that what you are suggesting is what the systemd folks are working on/researching.

You might want to look into what they are doing for booting a fully trusted system.

9

My idea is similar but a bit different.

They want a POS-style system with nil customizability, cattle-herding all systems.

My goal is to have a simpler more carefully prepared and tailored initramfs than one generated every so and on, with more features. This is if the initramfs can load configs from an external source… What simpler than unpacking another cpio?

10

This is not what they are aiming for.

The problem they are researching a solution to is how to have a trusted boot chain that prevents tampering AND allow the user to customise the boot process.

This is not an easy problem to solve, but they are making good progress from what I see.

11

(I have now corrected my knowledge to know that systemd’s idea infact does support customizability, as you pointed out)

In the process, they’ve surprisingly good progress. Great actually.

Mainly the positive effect is that dracut’s initqueues are lesser a requirement.

For example, rd.break= provided by dracut’s initqueue scripts is now provided by systemd as rd.systemd.break= on the kernel command like. With I guess more standardized arguments.

And a lot more I’d not like to list here for brevity.

AND that a general startup sequence of systemd units can be easily arbitrarily modified to include extra units in the middle of a boot chain of services, this is what makes my idea possible.

I can write a systemd unit (or few) to unpack the cpio on the running initramfs and a systemctl daemon-reload or whatever, a few extra units will be plugged into the systemd boot sequence cleanly. (Based on Wants= Requires= After= Before= etc.. in the units)

This and many other things, including the amazing tools provided by systemd (most under /usr/lib/systemd/) relevant to booting, allows one to prepare the “base” initramfs of my idea to be prepared using exclusively systemd (maybe a handwritten script initially)

1 Like
12

It now has a repository for contributors: MyFedoraContrib / Modular and streamlined initramfs · GitLab