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.
