felhom.eu/documentation/audits/SPIKE-universal-iso-4-2026-07-31.md

SPIKE 4 — can a .deb in the ISO deliver the stub on an interactive install? (2026-07-31)

Class: Spike. Findings only. No production file changed, no release ISO built, nothing published.

Continues SPIKE-universal-iso-{1,2,3}-2026-07-31.md. Spike 3's Q1 result and its Install.pm reading are premises and are not re-derived.

Q1 is YES, measured, with a control — and the negative control sits in the same box. On a normal interactive install the Felhom .deb is installed, its postinst runs, it enables a systemd unit, and that unit fires on first boot — while on that same machine the PVE first-boot hook is absent exactly as Spike 3 measured. The two mechanisms are independent, and the one that survives the interactive path is the .deb.

---

1. Venue — stated first, while it exists

Host	demo-hp (t740), Tier 0, the designated drill + build VM host
VMs	400 spike4-interactive (the test) · 401 spike4-auto-control (the control)
Storage	spike4, a dir storage created for this run at /mnt/nvme-1tb — the mount ROOT, not a subdirectory, content=images
Why the root	the agent's exactMount check reads a storage at a subdirectory of a mountpoint as disconnected forever. Placing it at the root avoids that. It coexists with the pre-existing felhom-backup dir storage on the same path (content=backup), which was not modified — the demo box's configuration is fenced
Disks	/mnt/nvme-1tb/images/{400,401}/vm-*-disk-*.raw. Nothing on local-lvm
Console	web console → VM → Console, or qm terminal <vmid> / qm monitor <vmid> on demo-hp. Both VMs were created with qm, so they appear in qm list and the web UI — unlike Spikes 1–3, which used raw QEMU processes PVE could not see
Teardown	VMs destroyed and the spike4 storage removed — §7

Baselines

Baseline	Value
ISO_VERSION	1.25.0 — scripts/iso/build-felhom-iso.sh:44
SCRIPT_VERSION	1.22.0 — scripts/felhom-host-install.sh:187
felhom-bootstrap.sh @ HEAD	21bf6a6bde0cb13e3809e2f5c136a49929dcc82eb8d40bbdf6f290a886ee8ab7
PVE base	proxmox-ve_9.2-1.iso, 4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c
felhom.eu HEAD	bb29186, clean, == origin/main

Fixture provenance

One ISO for both paths. Built on DooPlex: baseline PVE ISO → prepare-iso --fetch-from partition --partition-label proxmox-ais --on-first-boot hook.sh → the probe .deb injected into /proxmox/packages/ → re-mastered. Final sha256 6f723910239bb7f333c952c1d1933ae3951f03c5b6cc536f15e33a8da37eba5f, verified identical after transfer to demo-hp. 15 GRUB menu entries (Automated + Graphical + Terminal UI + the rest), so control and test come from the same build.

The probe .deb (felhom-spike4-probe_0.0.1_all.deb, 2016 bytes) carries no Felhom logic — a postinst that writes a marker and reports its environment, plus a trivial systemd unit and script. It tests delivery, not payload.

Completion signals: the automated control used reboot-mode = "power-off" (guest powers itself off); the interactive install's completion was observed on the console and then by an SSH banner from the installed system. No install was judged complete from a changed artifact (Spike 1's LastRun lesson) — and that mattered here: an ARP reply from 192.168.0.100 initially looked like the installed system and was in fact the installer environment, caught by screendumping the console, which showed the install still at 67 %.

---

2. Q1 — does the .deb reach the installed system? YES, both observables, on both paths.

The two observables are kept separate because "package present, postinst did not run" is a distinct and important outcome.

Observable	Control — Automated entry (VM 401, spike4auto.local)	Test — Terminal UI entry (VM 400, spikefour.felhom.eu)
A. package installed (dpkg -l)	ii felhom-spike4-probe 0.0.1	ii felhom-spike4-probe 0.0.1
B. postinst ran (marker + content)	/var/log/SPIKE4-POSTINST, 543 B, intact	/var/log/SPIKE4-POSTINST, 542 B, intact
unit enabled	enabled	enabled
unit fired on FIRST BOOT	@@SPIKE4_FIRSTBOOT_RAN@@, uptime 7.92 s	@@SPIKE4_FIRSTBOOT_RAN@@, uptime 7.98 s
PVE first-boot hook (SPIKE4-HOOK)	present — @@SPIKE4_HOOK_FIRED@@	absent
proxmox-first-boot package	installed	no packages found
/var/lib/proxmox-first-boot/	present	absent

The last three rows are the point. On one machine, from one image, the .deb arrived and the PVE first-boot hook did not. Spike 3's negative is reproduced here rather than assumed, and the .deb mechanism is proven independent of it.

Did the repack preserve the .deb? Yes, and the answer is more useful than a simple yes.

• A naive in-place xorriso … -boot_image any replay -map … fails: libisofs: FAILURE : Overlapping MBR partition entries requested.
• iso-repack.sh:270-292 documents this exact failure and its fix: re-master from the ISO's own -report_el_torito as_mkisofs report with -V, --modification-date=, -apm-block-size, -hfsplus, -part_like_isohybrid and -isohybrid-gpt-basdat filtered out, pinning the volume id and modification-date so the embedded fs-uuid stays valid.
• Mirroring that in a throwaway script produced a working image: 19 El Torito boot entries (iso-repack.sh:298 requires ≥2), 543 .debs, and the probe .deb extracted back out of the finished ISO is byte-identical to the input (sha256 first 32: c624acec93aa9450ac168d39e877807f both sides).

So the delivery path is: add the .deb to /proxmox/packages/ in the extract tree, and re-master with the existing recipe. Felhom's own repack already performs that extract→modify→re-master cycle, so this is an insertion into a step that runs anyway — not a new build stage.

Mechanism, from Spike 3 and confirmed visually here: Install.pm:1343-1372 unpacks every .deb in /proxmox/packages/ with a fixed skip-list of known package-name patterns, then dpkg --force-confold --configure -a at :1378 runs the postinsts. The console screendump caught the loop mid-run (67 %, extracting mesa-libgallium_25.0.7-2_amd64.deb).

---

3. Q2 — what a postinst can do from the installer chroot

The postinst reported its own environment. Identical on both paths, which is itself worth noting — the chroot does not differ between automated and interactive installs:

Property	Value	Consequence for a real postinst
pid1_comm	unconfigured.sh	it is the installer chroot, not a booted system
systemd_running (/run/systemd/system)	no	systemctl start / daemon-reload are meaningless — never call them
systemctl_path	/bin/systemctl	present, and usable in offline mode
systemctl enable	SUCCEEDED — Created symlink '/etc/systemd/system/multi-user.target.wants/spike4-firstboot.service' → …	enabling a unit works; no need to hand-write the symlink
/proc, /sys	both mounted	ordinary file/proc operations are fine
default_route	default via 192.168.0.1 dev ens18	network happened to be up — see the caveat below
dns_resolvable	yes	ditto
postinst arg	configure	standard dpkg first-install invocation

Answering Q2.2 directly: yes. The realistic job — drop a unit, enable it, exit — works, and the unit fired on first boot on both installs (uptime ≈ 8 s, pid1: systemd, network up).

The constraints a real postinst must respect, so they are written against rather than discovered:

1. Never systemctl start, daemon-reload, or anything needing a running systemd. There isn't one. enable is the only systemd verb available.
2. Never require the network, even though it was present. It was present only because the installer had DHCP and the chroot inherits its network namespace. A box installed with the cable out, or on a LAN with no DHCP, gives a postinst with no route — and a postinst that fails takes the whole install down. Fetch nothing; ship what is needed inside the package.
3. Never fail. dpkg --configure -a runs it; a non-zero exit surfaces as an install error to a customer mid-install. Guard everything and exit 0.
4. Do the real work in the unit at first boot, not in the postinst. The postinst's only job is to place files and enable the unit. That is also where network, systemd and a booted kernel actually exist.
5. Ordering within dpkg --configure -a was not tested. The probe depended on nothing. A package that needs another configured first is unproven here — see §6.

---

4. Q3 — can the image ship with no answer.toml?

Where it refuses — cited. scripts/iso/iso-repack.sh:100-106:

AIM="$(find "$EX" -maxdepth 2 -iname 'auto-installer-mode.toml' | head -1)"
[[ -n "$AIM" ]] || {
    echo "iso-repack: auto-installer-mode.toml not found in the ISO — this is not a prepared" >&2
    echo "  auto-install ISO, so the single Felhom entry would boot the MANUAL installer. Refusing." >&2
    exit 10
}

It is a guard, not a structural requirement, and its reasoning is sound for the shape it was written for: the Felhom menu emits exactly one entry which boots the automated installer, so an ISO without the mode file would put a "Felhom telepítés" label on a manual disk-picker. That is precisely the outcome the single-entry menu exists to prevent.

Under the operator's ruling the premise is inverted — the menu should offer the interactive installer deliberately — so the guard now blocks the desired shape. It needs to distinguish "prepared, single-entry" from "unprepared, interactive-by-design" rather than treating the second as the first's failure. Already filed as R-155; this session cites the exact refusal.

Does the automated entry degrade gracefully with no answer file? Two measurements bear on it:

• With no auto-installer-mode.toml at all, the stock grub.cfg does not emit the Automated entry — it sits inside if [ -f auto-installer-mode.toml ] (Spike 1 §5). So the entry is absent, not broken. Nothing to hang.
• With the mode file but no reachable answer, observed incidentally this session (Spike 3's VM rebooting into the CD): the automated entry aborts safely and loudly — INFO: Testing partition search path "/dev/disk/by-label/proxmox-ais" … ERROR: Aborting: Could not find any answer file! … Installation aborted - unable to continue (type exit or CTRL-D to reboot), leaving a shell and touching no disk.

Not measured: whether an ISO that never went through prepare-iso boots and installs correctly after Felhom branding. That needs the guard relaxed, which is a production-code change this spike is fenced from making. See §6.

Release gate, if the posture is adopted: osirrox -indev <iso> -find / -maxdepth 1 contains neither /answer.toml nor /auto-installer-mode.toml. One line, checkable against the artifact.

---

5. Q4 — the resulting product shape, as constraints

Given the ruling (no fully automatic install) and Q1/Q2 positive. Constraints on a build spec — not an implementation, and nothing was built.

#	Constraint	Release gate (checkable against the artifact)
1	No answer.toml, and no auto-installer-mode.toml. Q1 makes the first-boot hook pointless on the shipped path; the ruling removes the automated path. Dropping both deletes the baked root hash, the disk profile and the whole Spike 1–2 problem space at once.	osirrox -find / -maxdepth 1 contains neither file.
2	A Felhom .deb in /proxmox/packages/ is the delivery mechanism. Measured (§2): it arrives and its postinst runs on the interactive path.	the ISO contains exactly one felhom-*.deb; extracting it back yields a sha256 matching the built package.
3	The postinst places files and enables a unit. Nothing else. §3's five constraints — no running systemd, no network dependency, never fail, real work in the unit.	the packaged postinst contains no systemctl start, no daemon-reload, and no network fetch (curl/wget/apt); it ends exit 0.
4	No baked credential of any kind — falls out of 1. The human sets their own password in the installer.	grep -c root-password-hashed and grep -c root-ssh-keys over the ISO both 0; no .rootpw.txt emitted beside the output.
5	The boot menu is restored, with an interactive entry as default and a human-length timeout. Spike 2 lost a probe to the installed system's 1-second menu; a person choosing between install paths needs far longer. The stock ISO uses 10 s.	grub.cfg: set default= points at an interactive entry; set timeout ≥ 10; timeout_style uses the underscore spelling (the stock hyphenated timeout-style is not a GRUB variable at all — Spike 2 §5.2).
6	Relaxing the menu gates means relaxing the count gates only. Four gates enforce the single entry (iso-repack.sh:153-155, :156, :160-164, :314-319). Keep the banned-token gate exactly as it is — it is what prevents a route to a debug/rescue/manual-disk-picker path, and a stock Graphical entry passes it unchanged.	grub.cfg still has no live proxtui/proxdebug/nomodeset/Rescue Boot/memtest/fwsetup; the entry-count assertion becomes an allowlist rather than == 1.
7	iso-repack.sh:100-106 must learn the new shape (R-155) before constraint 1 is buildable.	the repack accepts an unprepared ISO when branding an interactive-by-design image, and still refuses one when emitting a single automated entry.
8	The profile the public image uses must be COMMITTED. Spike 1 found demo-felhom's baked SSH key comes from an uncommitted profile, so a Tier 0 reference box is not reproducible from main.	--profile resolves inside the repo tree and git status --porcelain is empty for it.
9	The artifact must be reproducible (R-144: nested-probe's profile no longer exists).	the manifest records the committed profile path + repo commit; both resolve.

The product this describes: insert the stick, install Proxmox normally choosing your own disk and password, and the box sets itself up and waits for a claim code. That is now measured, not hoped for — with the caveat that what was measured is a trivial probe package, not Felhom's real stub (§6).

---

6. R-153 / R-94 — reconciled. R-153 is retracted.

The register grep the fence requires was run, and it shows Spike 3 should not have minted a row.

• OPEN-ITEMS.md:15 — R-94, status READY (XS), states the finding verbatim: "A hand-synced version constant drifts, and the gate that would catch it is never run — hub/internal/web/configs.go:28 pins hostInstallVersion = "1.19.0" while scripts/felhom-host-install.sh:187 is SCRIPT_VERSION="1.22.0"", with leg (b) being exactly "scripts/hostinstall_gates.py fails today and is invoked by no Makefile, hook or CLAUDE.md — wire it or delete it."
• OPEN-ITEMS.md:27 — R-29 is the class, and says in terms: "do not mint a new ID for a new instance" — it already absorbed a third independent re-raise on 2026-07-29 without minting one, and already names scripts/hostinstall_gates.py as R-94 leg (b).

So R-153 duplicates R-94 leg (b) and violates R-29's explicit instruction. It is retracted here and should be struck from Spike 3's row list. Nothing is lost: R-94 covers it in more detail.

A second correction, and this one matters more. Spike 3's report claimed the drift meant "the customer page's install-command generator targets a flag surface three minor versions stale." That is false, and R-94 explicitly retracts exactly that reading. The constant selects no script: its only consumers are configs.go:487 and render_test.go:219, and it renders as a text label at customer_unified.html:494. The command beneath it fetches https://felhom.eu/scripts/felhom-host-install.sh, which the website git-syncs from main on a 30 s period — so 1.22.0 is what every install already gets, and every flag the generator emits is parsed by it. The defect is a wrong number on the operator's screen, nothing more. Spike 3's sentence overstated it and is corrected here.

The lesson for this arc: the fence that caught this — grep the register before minting — worked, and it worked one session too late. R-123 names this exact class.

---

7. What is still unknown

#	Unknown	What it takes
1	The real Felhom stub has not been packaged. §2 proves a trivial .deb is delivered and its postinst can enable a unit that fires. It does not prove felhom-bootstrap.sh + its unit + the pairing env survive that route, nor that pairing completes end-to-end from an interactively-installed box.	Package the real stub as a .deb per §3's constraints, repeat the §2 run, and confirm pairing reaches the hub. ~60 min. This is the last thing between here and a spec.
2	dpkg --configure -a ordering (§3, constraint 5) — the probe depended on nothing.	A package with a dependency, or one that must run after pve-manager. Only matters if the real stub needs it.
3	An ISO that never went through prepare-iso (§4) — unmeasured, and blocked by R-155 which this spike is fenced from changing.	Relax the guard in a branch, build, boot. ~30 min.
4	Spike 3's Q3 — the real stub at before-network — this session did not touch it. It now governs operator-built images only, and note item 1 partly supersedes it: on the .deb route the unit's ordering is set by the unit file, not by [first-boot].ordering.	~40 min if still wanted.
5	The graphical installer was not tested — §2 used the Terminal UI. proxinstall has strictly less first-boot capability, and the .deb path does not involve the front-end at all (it is Install.pm, shared), so the result should hold a fortiori — but that is inference.	Repeat §2 via the Graphical entry. ~30 min.
6	Spike 1's two open items — multi-match determinism, boot-medium exclusion.	Unchanged.

---

8. R-rows opened

None. Each candidate was grepped against the register first, per the fence:

• The .deb delivery result is a positive finding, not a defect.
• The postinst constraints (§3) belong in the eventual build spec, not the defect register.
• The iso-repack.sh guard is already R-155 (opened by Spike 3) — extended here with the exact citation rather than duplicated.
• R-153 is retracted into R-94 leg (b) / R-29 (§6).

---

9. Teardown

Layer 1 — demo-hp, including the scratch storage.

Check	Result
VMs 400, 401	qm destroy --purge — "purging VM 400/401 from related configurations"; qm list now shows only 300 drill-r50 stopped
scratch storage spike4	pvesm remove spike4 — removed; /etc/pve/storage.cfg back to 4 storages, grep -c spike4 = 0
/mnt/nvme-1tb/images/	empty — both VM disk directories gone with the purge
/mnt/nvme-1tb/ contents	dump e2d-images felhom-data images lost+found — the pre-spike set
disk usage	6.6 G — identical to pre-spike
probe4.iso in the ISO store	removed
driver, answer file, password files, screendumps (/root/…)	all removed
loop devices / /mnt/s4ans	0 / removed
drill-r50 (VM 300)	stopped, untouched — never destroyed or unblocked (R-93 fixture intact)
guest 9201	running, untouched
felhom-backup storage	unmodified — the demo box's own configuration was not changed
local-lvm	never written

Layer 2 — demo-felhom. Nothing was placed there this session; it was not contacted.

Layer 3 — DooPlex.

Check	Result
workspace scratch /mnt/5_hdd/felhom.eu/spike4-scratch (ISO extract tree + two 1.7 GB ISOs)	4.8 GB → removed; /mnt/5_hdd at 24 %
session scratchpad	3.3 GB → 88 K
throwaway passwords	the answer-file password shred -u'd and verified absent; the interactive install's console password existed only as a 0600 file on demo-hp, deleted in the same command
probe .deb build tree	removed
felhom-iso/out/	untouched, 17 ISOs
production files	none modified — no build-felhom-iso.sh, no iso-repack.sh, no profile, no answer.toml.tmpl, no felhom-bootstrap.sh

Note: the ISO extract used disk-backed workspace scratch, not /tmp — /tmp on DooPlex is a 32 GB tmpfs, and a 3.4 GB extract there would have taken RAM from a live k3s node.

Hub-side disposition. No customer, host or appliance was created. The VMs were bridged to the demo-site LAN and took DHCP leases (192.168.0.47, 192.168.0.100), but neither ran felhom-host-install.sh nor contacted the hub — the probe package carries no Felhom logic. Verified by fetching the customer list and searching it, not asserted.

Published artifacts: none.