Repository navigation
cli: Un-hide bootupctl backend and document its verbs - #1
cgwalters-bot wants to merge 5 commits into
Conversation
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`
|
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: https://github.com/cgwalters/#llms |
|
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: Generated-by: https://github.com/cgwalters/#llms |
|
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: 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
528e9bf to
a5fa13e
Compare
|
Opened upstream as coreos#1169. Closing this review draft. |
bootupctl backendwas 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 referencebackend install,generate-update-metadataandset-default-bootloader, yet--helpgives no hint that these exist or what they are for.The first commit is a prep:
bootupctl backendhad its own hand-synced copy of thebootupdverbs, each individually hidden, so it now reusesDVerband both entrypoints share one set of verbs and help text. The second showsbackendinbootupctl --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 atupdateandadopt-and-update. A unit test keepsbackendand its verbs visible and documented.For maintainers: this reverses the intent of the removed
FIXME(lucab)comment, which planned to eventually dropbackendfrom 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 installis 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, andcargo test --all-targets(40 passed, 1 ignored). I also checked thebootupctl --helpandbootupctl backend --helpoutput 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.
coreos/bootupd, basemainPVTI_lADOE9oHIs4BlJLczg9kEKITo review:
/promoteon a line of its own, to open it upstream, ready for review. Either covers only the commits pushed so far.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./draftline (in the same comment or before) to open it upstream as a draft (/readyundoes that).