Skip to content

status: Add --sysroot flag to query non-booted sysroots#2299

Open
cgwalters wants to merge 1 commit into
bootc-dev:mainfrom
cgwalters:status-sysroot
Open

status: Add --sysroot flag to query non-booted sysroots#2299
cgwalters wants to merge 1 commit into
bootc-dev:mainfrom
cgwalters:status-sysroot

Conversation

@cgwalters

@cgwalters cgwalters commented Jul 8, 2026

Copy link
Copy Markdown
Collaborator

Add bootc status --sysroot <path> to query the deployment state of an sysroot at an arbitrary path. This is designed for install tooling (Anaconda, osbuild, custom installers) that needs to discover deployment metadata immediately after installation without rebooting.

The returned Host uses the same schema as bootc status --json. Since the target sysroot is not the running system, booted and staged are null -- all deployments appear in otherDeployments, ordered by priority (first entry is what will boot next).

Assisted-by: https://github.com/cgwalters/cgwalters#llms
xref #542

@github-actions github-actions Bot added the area/documentation Updates to the documentation label Jul 8, 2026
@bootc-bot bootc-bot Bot requested a review from gursewak1997 July 8, 2026 21:40

@Johan-Liebert1 Johan-Liebert1 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. Just not sure about whether we need the bootloader stuff. We could definitely allow querying even if an ESP isn't mounted at sysroot/boot

.open_dir_optional("boot/efi")?
.filter(|d| d.exists(TYPE1_ENT_PATH) || d.exists(EFI_LINUX))
{
(esp_dir, Bootloader::Systemd)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also be GrubCC but we have no way of knowing I guess

};

let storage = Storage::new_composefs_sysroot(sysroot_path, sysroot_dir, boot_dir)?;
let bootloader_entries = list_bootloader_entries(&storage, bootloader)?;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should do this. We shouldn't care about the bootloaders or bootloader entries when querying an arbitrary sysroot. We can definitely base our assumptions by looking at the sysroot/composefs/images or sysroot/state directories. This would cut down a lot of changes in this PR

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bootloader entries are the source of truth for what gets booted, which is a key concept here in the general case. That said, our current API is much more designed around what a booted system looks like.

That said, there's already e.g. bootctl --list and arguably what we want I think is an extension of that that additionally returns ostree/composefs metadata instead of trying to shim things into our existing status API?

Or perhaps we try to implement that new API as part of #522

Add `bootc status --sysroot <path>` to query the deployment state of
an sysroot at an arbitrary path. This is designed for install
tooling (Anaconda, osbuild, custom installers) that needs to discover
deployment metadata immediately after installation without rebooting.

The returned Host uses the same schema as `bootc status --json`. Since
the target sysroot is not the running system, `booted` and `staged`
are null -- all deployments appear in `otherDeployments`, ordered by
priority (first entry is what will boot next).

Assisted-by: https://github.com/cgwalters/cgwalters#llms
Signed-off-by: Colin Walters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/documentation Updates to the documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants