Skip to content

cli: Un-hide bootupctl backend and document its verbs - #1

Closed
cgwalters-bot wants to merge 5 commits into
mainfrom
bot/unhide-backend-verb
Closed

cgwalters-bot wants to merge 5 commits into
mainfrom
bot/unhide-backend-verb

Conversation

@cgwalters-bot

@cgwalters-bot cgwalters-bot commented Sep 24, 2026 •

Copy link
Copy Markdown
Collaborator

bootupctl backend was hidden to keep the client side less confusing, but hidden commands cause more confusion than they avoid. Image build tooling uses it, and our own README, Dockerfile.bls and tests reference backend install, generate-update-metadata and set-default-bootloader, yet --help gives no hint that these exist or what they are for.

The first commit is a prep: bootupctl backend had its own hand-synced copy of the bootupd verbs, each individually hidden, so it now reuses DVerb and both entrypoints share one set of verbs and help text. The second shows backend in bootupctl --help, after the verbs for a booted system. It gets help text saying these commands act on an OS tree or target root at build/install time, and pointing users who want to update a running system at update and adopt-and-update. A unit test keeps backend and its verbs visible and documented.

Commands:
  status            Show components status
  update            Update all components
  adopt-and-update  Update all adoptable components
  validate          Validate system state
  backend           Low-level commands for building and installing OS images

For maintainers: this reverses the intent of the removed FIXME(lucab) comment, which planned to eventually drop backend from bootupctl after coreos/fedora-coreos-config#595. Since image build tooling still relies on it, documenting it seems better than keeping it half-hidden.

The issue also suggests detecting a booted system and giving clearer guidance there. That is not done here, because backend install is legitimately run on a booted host (e.g. bootc install to-existing-root), so a simple "systemd is running" check would misfire. The help text covers the guidance for now. So this is related to coreos#1119 rather than closing it.

Testing, on a 16-core devspace in rust:1.90.0 (the pinned lint toolchain in rust.yml): cargo fmt -- --check, cargo clippy --all-targets -- -D warnings, and cargo test --all-targets (40 passed, 1 ignored). I also checked the bootupctl --help and bootupctl backend --help output by hand.

Related: coreos#1119

Generated-by: https://github.com/cgwalters/#llms


Review draft in cgwalters-forge, not upstream yet. This section is removed when the PR is opened upstream.

  • Upstream: coreos/bootupd, base main
  • Board item: PVTI_lADOE9oHIs4BlJLczg9kEKI
  • Fork CI: off; the devspace testing described above is this PR's CI, and upstream CI runs once it is opened there

To review:

  • Approve, or comment /promote on a line of its own, to open it upstream, ready for review. Either covers only the commits pushed so far.
  • If upstream requires DCO, approving also signs off: promote adds Signed-off-by: Colin Walters <walters@verbum.org> to the commits lacking it (the bot's and yours; anyone else's only if you ask), with you as committer.
  • Add a /draft line (in the same comment or before) to open it upstream as a draft (/ready undoes that).
  • Close to drop it.
  • Edit the title and description freely: they become the upstream PR's. Review comments are squashed into the commits they concern, with a reply here.

Johan-Liebert1 and others added 3 commits October 1, 2026 15:31
We have cases where `grub2/grub.cfg -> ../loader/grub.cfg` and
since we moved to cap-std APIs, the metadata gathering for the file
fails since the target leads to outside the filesystem (which is the
directory `grub2` in this case).

To fix, use `std::fs` APIs to get metadata

Use `GRUBCONFIG_FILE_MODE` constant instead of raw 0600 mode

Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
bootc 1.16.14 (in copr) uses composefs.digest= cmdline, but since we
don't rebuild the initramfs, we never include that digest as a condition
for bootc-initramfs-setup to run which fails the VM startup

Disable C10S tests for composefs, for now

Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
grubcfg: Handle symlink that lead outside of `grub2`
@cgwalters-bot

Copy link
Copy Markdown
Collaborator Author

Not promoted: coreos/bootupd is human-text, so the title, body and commit messages sent there must be yours.

Next: edit this PR's title and body (dropping the Generated-by line), reword the commits and push them to this branch yourself, then comment /promote --human-text on a line of its own.

Generated-by: https://github.com/cgwalters/#llms

@cgwalters-bot

Copy link
Copy Markdown
Collaborator Author

Upstream LLM rules (advisory): coreos/bootupd's contribution policy record says human-text: code by the bot is fine, but the PR title and body, commit messages and comments must be cgwalters' own, except an answer on a thread where cgwalters summoned the bot. AI trailer: default (Generated-by: AI); nothing written, and precedent on main is Assisted-by (2 of the last 100 commits). The text sent there must be yours; the next comment says how.

Record: upstream-policy/coreos/bootupd.md, checked 2026-09-25 by the policy-check subagent (coordinator session 929c7a64, converted from an earlier read-only survey and re-read against current upstream).

Generated-by: https://github.com/cgwalters/#llms

@cgwalters-bot

Copy link
Copy Markdown
Collaborator Author

Upstream LLM rules (advisory): coreos/bootupd's contribution policy record says bot-ok: the bot may write the code and the text, with the AI trailer. AI trailer: default (Generated-by: AI); nothing written, and precedent on main is Assisted-by (2 of the last 100 commits). Nothing here holds this PR back: the bot promotes it now.

Record: upstream-policy/coreos/bootupd.md, checked 2026-09-25 by the policy-check subagent (coordinator session 929c7a64, converted from an earlier read-only survey and re-read against current upstream).

Generated-by: https://github.com/cgwalters/#llms

`bootupctl backend` had its own copy of the `bootupd` verbs that had to
be kept in sync by hand, and its variants were each individually hidden.
Share the one enum so both entrypoints get the same verbs and help text.

Prep for un-hiding `backend`.

Generated-by: AI
Hiding `backend` was meant to keep the client side less confusing, but
in practice hidden commands cause more confusion than they avoid: they
are used by image build tooling and referenced in our own docs, yet
`--help` gives no hint they exist or what they are for.

Show it, listed after the verbs for a booted system, and give it and
its verbs help text that explains they operate on an OS tree or target
root at build/install time, pointing users who want to update a booted
system at `update` and `adopt-and-update`. Add a test so the verbs stay
visible and documented.

Note this reverses the intent of the deleted FIXME(lucab) comment,
which planned to eventually drop `backend` from bootupctl once
coreos/fedora-coreos-config#595 was refreshed. Since image build tooling
still relies on it, making it a documented interface seems better, but
that is a call for the maintainers.

Related: coreos#1119
Generated-by: AI
@cgwalters-bot
cgwalters-bot force-pushed the bot/unhide-backend-verb branch from 528e9bf to a5fa13e Compare October 7, 2026 21:36
@cgwalters-bot

Copy link
Copy Markdown
Collaborator Author

Opened upstream as coreos#1169. Closing this review draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants