Re: [RFC PATCH 0/2] init: boot image-based systems without an initramfs (rootimage=)

["Colin Walters" <walters@verbum.org>]

On Sat, Jul 18, 2026, at 3:15 PM, Eric Curtin wrote:
> Image-based Linux systems (bootc-style OS updaters, ChromeOS/Android-like
> A/B schemes, embedded appliances) keep one or more immutable root
> filesystem images as sealed files on a writable filesystem and pick one
> at boot.  Booting such a system today always requires an initramfs, even
> when that initramfs has nothing else to do; its only jobs are to parse
> the kernel command line, mount the state filesystem, verify the image,
> loop-mount it and switch_root into it.

What's the higher level goal? Is it boot speed? That's my guess, but this needs to be stated explicitly and I'd really like to see some numbers on this. If you're using LLMs to do this kind of stuff, there's ~no excuse not to spend the tokens to generate benchmarks and things.

Also, we need to weigh this approach vs "static initramfs binary"; AFAIK it has historically been pretty common in some embedded/appliance style setups to have the initramfs basically be a single statically linked binary (and if I was doing this, it'd be in Rust nowadays). That's a wildly different thing than the typical dracut or equivalent thing, *especially* if you're comparing this approach vs a non-appliance general purpose initramfs.

At least for the composefs case, I bet it'd be quite easy to get to that single static Rust binary, and at a high level putting that into e.g. a UKI seems to me a lot more preferable than trying to push all of this into the Linux kernel core.