Skip to main content

max / alloy

install: record what the first real bootc run settled The deploy half has now run against bootc 1.16.3, installing to a scratch device from inside the image. to-disk completed, the DPS root GUID the discovery matches on is the one bootc sets, and the stateroot var it leaves holds cache/lib/log/run/tmp and no home -- the fact the --no-create-home workaround is built around. install finalize is no longer a guess. --help gives `finalize <ROOT_PATH>`, the mounted root filesystem, so the argument was right. It describes itself as part of an install to-filesystem flow though, and to-disk already finalizes and unmounts on its own; against a real to-disk install it exits 0 silently. Kept as a cheap sanity check, with the comment no longer claiming more for it than that. The configure half still has not been driven end to end by the wizard, which needs a terminal. Said so plainly rather than leaving the header implying more coverage than there is.
Co-Authored-By
Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-07-20 17:41 UTC
Signed with PGP, not checked
Commit: ec9e74235466801b8c630678673edad6749a536b
Parent: f03ae00
1 file changed, +24 insertions, -6 deletions
@@ -33,9 +33,23 @@
33 33 //! is mounted over at boot; the home is made in the stateroot var instead. Both
34 34 //! are documented where they happen.
35 35 //!
36 - //! **The rest has not run against real bootc.** The shape follows upstream's
37 - //! documentation, and the pieces that are guesses rather than quotes are the
38 - //! arguments to `bootc install finalize`, which that page does not document.
36 + //! The deploy half has since run against real bootc 1.16.3, installing to a
37 + //! scratch device from inside this image. `bootc install to-disk` completed,
38 + //! the DPS root GUID the discovery matches on is the one it sets, and the
39 + //! stateroot var it leaves holds `cache lib log run tmp` and no home, which is
40 + //! what the `--no-create-home` workaround is built around.
41 + //!
42 + //! `bootc install finalize` is no longer a guess: `--help` gives
43 + //! `finalize <ROOT_PATH>`, "path to the mounted root filesystem", so the
44 + //! mountpoint was the right argument. Note it describes itself as a step of an
45 + //! `install to-filesystem` flow; run against a `to-disk` install it exits 0
46 + //! silently, and `to-disk` already finalizes and unmounts on its own. The call
47 + //! is kept as a harmless assertion rather than removed, but it is doing less
48 + //! than its comment below implies.
49 + //!
50 + //! **What still has not run: the configure half in sequence.** `useradd`,
51 + //! `chpasswd` and the ownership fixups have been exercised against a target
52 + //! individually, not driven end to end by the wizard, which needs a terminal.
39 53 //!
40 54 //! <!-- wiki: alloy-console -->
41 55
@@ -558,9 +572,13 @@
558 572 // Upstream: "optional, but recommended to run as the penultimate step
559 573 // before unmounting the target filesystem. This command will perform
560 574 // some basic sanity checks and may also perform fixups on the target
561 - // root." Its arguments are not documented on that page; the mountpoint
562 - // is passed positionally, which is the one thing it plausibly wants and
563 - // is flagged in the module header as unverified.
575 + // root." `--help` confirms the shape: `finalize <ROOT_PATH>`, the
576 + // mounted root filesystem, which is what is passed.
577 + //
578 + // It bills itself as a step of an `install to-filesystem` flow, and
579 + // `to-disk` already finalizes and unmounts by itself. Against a real
580 + // to-disk install this exits 0 without output, so it is kept as a
581 + // cheap sanity check rather than for any fixup it is known to make.
564 582 Stage::Run(
565 583 Invocation::new("bootc")
566 584 .args(["install", "finalize"])