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

[Eric Curtin]

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
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.
 - 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
already-resolved, already-open file and make it root, verified"
problem, drop the multi-knob framing, and either fix the fd-vs-path
lookup properly or wait for the generic "mount from fd" infra you
mentioned.

Thanks for going through this in such detail.

Eric