Userspace configuration is not captured as code #8
Labels
No labels
blocked-physical
cleanup
hardware
infra
kernel
P1-critical
P2-high
P3-normal
P4-later
reliability
security
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tiagoagueda/a80#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The running system is the product of a long interactive session and cannot currently be
rebuilt without repeating it from memory. Hand-made state includes:
ir-protocols.service,bt-public-addr.service(+/usr/local/sbin/bt-public-addr.sh)/lib/firmware/brcm/BCM4335C0.hcd(note the rename — seefirmware/README.md)10-any-eth.networkwithActivationPolicy=always-up,20-wlan0.network,ifupdown neutralised
10-watchdog.conf), journald size capDone when
provision.sh(or Ansible role) in this repo reproduces all of the above on a freshDebian rootfs
Done —
tools/provision/, and testing it from scratch found three real defectstools/provision/holds afiles/tree mirroring the filesystem,packages.txt, and an idempotentprovision.sh. A second run printing nothing but=is the point: that is how drift shows up.On the two done-when boxes
Box 1 is met literally. It was run against a fresh
debootstrap --variant=minbase trixie armhftree, twice, and the result compared against the live board: 0 files differ, 0 packages installed that the board does not have,dracoidentical, all four firmware blobs identical.Box 2 I did not do as written, and the substitution is better. It asked for verification against the rescue SD. That card is now a full clone of the eMMC, so running there would report
=on every line and prove nothing at all. A bare rootfs is the harder test, and it earned its keep immediately.What testing from scratch caught that the on-board run could not
The on-board run reported 16/16 green. It was still wrong three times over, because passing against a system that is already correct only proves the script recognises that system — not that it can build one.
e2fsprogs,cron,nftables,systemd-timesyncdwere missing. The root filter excluded everything Debian installs at priority important/standard, but--variant=minbaseinstalls neither. Withoute2fsprogsthe entire fsck policy from #14 is inert on a rebuilt system.Recommends were on while the board was built without them, pulling in 23 packages it does not have — including a whole
evolution-data-serverstack behindbluez-obexd.Turning recommends off then dropped two packages that fail silently:
libubootenv-toolprovidesfw_printenv/fw_setenv, whichboot-mark-goodcalls. Without it the U-Boot bootcount is never cleared, soBOOTCOUNT_LIMITfalls back touImage.known-goodafter three perfectly good boots.wireless-regdbprovidesregulatory.db, which the initramfs hook copies. Without it cfg80211 never leaves the world domain — the exact bug fixed on the rescue card earlier today, reintroduced by rebuilding from this script.Neither produces an error. The board would boot, look healthy, and be quietly wrong.
Three decisions worth recording
packages.txtis 48 names, not 237.apt-mark showmanualreports 237 includingbashandcoreutils. Subtracting Debian's priority set leaves 163, still mostly dependency noise. Keeping only the roots of the dependency graph leaves 28; the rest are the minbase gaps and the needed recommends, both marked in the file. That filter also droppedgcc-arm-linux-gnueabihfand its toolchain, installed at some point on a board that is itself ARM — provisioning will not put them back.The NVRAM is not installed verbatim.
firmware/nvram_ap6335.txtis the vendor original withccode=0. The script appliesCCODEat install time, so a local edit is visible rather than hidden inside a file labelled "vendor".rdregis compiled, not committed — it was a 490 KB static ARM binary; the source is inusb3-re/rdreg.c.The gap this exposed, left open on purpose
This board has no working module tree.
/lib/modulesholds directories for two older kernels and none for the running one, anddeploy-kernel.shnever runsmake modules_install, somodprobecannot work at all. Nothing has noticed because everything needed is built in — which is also whyCONFIG_ZRAMwent in as=yrather than=m.provision.shprints this at the end of every run rather than burying it. It deserves its own issue: no provisioning script can honestly claim to rebuild this system until module installation is part of the deploy.