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

[Christian Brauner]

On 2026-07-27 11:31 +0100, Eric Curtin wrote:
> On 2026-07-27 10:55 +0200, Christian Brauner wrote:
> > So I have several structual and design issues with this.
> [...]
> > You're embedding a whole deployment topology into the core code here as
> > well... There are _five_ interacting __setup parameters. Every real
> > deployment immediately wants a sixth knob: A/B fallback inside the
> > mechanism. Because in your current model every failure is a panic().
> >
> > But that also means image selection must live in the bootloader anyway:
> > composefs/overlay stacking, LUKS-encrypted state partitions as command
> > lines can't do crypto secrets, fsck of the carrier, directory-based
> > deployments yadayadayada.
> >
> > This is just turning do_mounts.c into policy it shouldn't be involved
> > in.
> 
> Thanks for the detailed review. Let me state the goal plainly, since I

This kinda reads like a complete 1:1 dump of an LLM session...

> think it explains the choices even though several of your specific
> findings below are real bugs I should just fix rather than defend.
> 
> The goal is A/B image updates from a *single* partition, without
> paying for a second userspace spin-up at boot.
> 
> Today there are basically two ways to do A/B on Linux:
> 
>  1. N partitions/dm-verity volumes, each a full root image, selected
>     by the bootloader (dm-mod.create= + a GPT attribute flip). This
>     is the ChromeOS/Android model. It costs Nx the storage/partition
>     budget up front and the slot count is fixed at provisioning time.
> 
>  2. A single filesystem holding N image files (what bootc/ostree/
>     composefs already do), where something picks which file becomes
>     root. Far more space- and slot-count-flexible, but "pick a file
>     and expose it as root" is currently dracut/initramfs's job, so
>     you pay for a whole extra userspace stage whose only work is the
>     five steps in the cover letter.
> 
> rootimage= targets (2): keep single-partition flexibility, drop the
> "spin up a second userspace just to switch_root" cost. On fast-boot
> targets that first userspace (loading dracut/busybox, forking,
> possibly loading modules) isn't free and is pure overhead for five
> mechanical steps.
> 
> To be clear, I'm not trying to relitigate "no bootloader spec in the
> kernel" - I agree with that call, and A/B slot selection/fallback
> bookkeeping is meant to stay in the bootloader, exactly as it does
> with dm-mod.create= today. rootimage= is only meant to do the same
> mechanical "resolve the one path the bootloader already chose, verify
> it, make it root" step dm-mod.create() does for partitions - just for
> the file-backed case, where there's no dm table to describe it. So
> the "sixth knob" is intentionally out of scope; where you're right is
> that I haven't specified what happens when this step fails (currently
> panic()), and that needs a real answer, not "bootloader's problem".
> 
> On the rest, these read like real bugs, not disagreements, and I'd
> rather fix them than defend the current code:
> 
>  - filp_open()/fput() unused, and no guaranteed relationship between
>    the fsverity-checked file and the path/inode init_mount() and
>    erofs's own filp_open(fc->source) resolve independently - agreed,
>    this needs a real "mount from an already-open fd" path.
>  - multi-device erofs / rootimageflags=device= meaning the digest
>    only covers the primary image - agreed, real gap.


>  - the carrier fs being fully parsed, including reading the fsverity
>    descriptor itself, before anything is verified - agreed, that
>    ordering defeats the point.

Yeah, and it's unaddressed as are all the other structurual issues.

>  - zombie superblock / dangling source path / no loop-style
>    backing-file equivalent after detach - agreed, needs fixing.
> 
> I'll rework this into a v2 that only tries to solve the "take an

Why? The structural issues are all still there.