veilor-os/test/test-runs/2026-05-06-v0.5.32-build.md

Test run — v0.5.32

• Date: 2026-05-06
• ISO: veilor-os-43-20260506-HHMMSS.iso (sha256: TBD — fill in once A1 reports the build artifact)
• Tester: A1 (build) + operator (P) + A5 (report scribe)
• Build host: forgejo-runner on nullstone (runner label ubuntu-24.04, image catthehacker/ubuntu:act-24.04); first ISO produced off the Forgejo build pipeline after the GH Actions mirror was disabled 2026-05-06.
• Environment: VM (qemu/q35/ovmf, 4 vCPU, 4 GiB RAM, virtio-vga, virtio-9p host log mount). Real-hardware run is a separate report — this file is the VM run only.

---

Result

⏳ Pending A1 build. Operator + A5 fill in pass/fail per-step once the actual VM test is walked through against the v0.5.32 ISO. Until the ISO sha256 lands here, treat every row in the per-step table as unverified.

One-line summary (write here once known): TBD.

---

Regressions vs previous run

(v0.5.31 was the last tagged release; compare against any pass-with-issues notes from that test run if a report exists. Empty otherwise — fill in during the actual test walkthrough.)

• TBD

---

Per-step results

Walk test/TESTING.md step-by-step. Mark each pass/fail with a brief note when failed. Until the test runs, every row is ⏳ pending.

#	Step	Result	Notes
1	Live boot to installer banner	⏳ pending
2	Installer menu render	⏳ pending
3	Disk picker	⏳ pending
4	LUKS + admin passwords	⏳ pending	Operator types directly into QEMU window — plymouth ignores synthesised keys.
5	Locale	⏳ pending
6	Confirm	⏳ pending
7	Anaconda transaction	⏳ pending
8	Reboot	⏳ pending
9	GRUB single veilor-os entry	⏳ pending
10	LUKS unlock prompt	⏳ pending
11	First boot → SDDM → KDE	⏳ pending
12	Hardening checks	⏳ pending

---

Hardening verification

$ getenforce
TBD

$ systemctl is-active fail2ban usbguard tuned auditd firewalld
TBD

$ cat /proc/cmdline
TBD — must include rd.luks.uuid=luks-... and the v0.5.32 cmdline set.

$ lsblk -f
TBD

$ systemctl is-enabled veilor-firstboot.service
TBD — must report enabled with WantedBy=graphical.target (blocker #2).

$ nft list ruleset | grep -i tailscale
TBD — tailscale0 must be in the trusted zone (blocker #5).

$ cat /etc/skel/.config/kdeglobals 2>/dev/null | head
TBD — branding must be present (blocker #6).

$ ls /var/log/anaconda/host-9p-mount/
TBD — virtio-9p Anaconda log capture (blocker #7).

Paste real output. If any service is inactive, any cmdline arg is missing, or any blocker artifact is absent, raise as a Regression above.

---

Findings

The 7 v0.5.32 blocker fixes from the 2026-05-05 9-agent research wave land in this build. Each is listed here as an expected behaviour the tester must observe — if any of these regress, log it under Regressions above.

1. Suspend/resume wifi survives lid-close. kernel.modules_disabled=1 no longer fires before the wifi module reloads on resume. Test: suspend the VM (or lid-close on real HW), wake, reconnect to the same network without manual modprobe.
2. veilor-firstboot.service is WantedBy=graphical.target. The first-boot admin password flow must run on real installs, not just on multi-user.target boots. Test: fresh install boots straight to the TTY password prompt before SDDM lights up.
3. Kernel-upgrade does not drift GRUB. First dnf upgrade kernel must leave the system bootable — grub2-mkconfig is wired into the kernel-install hook. Test: install, run sudo dnf upgrade kernel, reboot, system comes up.
4. USBGuard rules are id-based, not hash + parent-hash. Mirrors the onyx dock-replug fix in feedback_usbguard_dock.md. Test: unplug/replug a known device — it stays allowed. The hash variant re-blocks on every replug; the id variant must not.
5. firewalld trusts tailscale0. The interface is in the trusted zone out-of-the-box. Test: bring tailscale up, ping a peer in the mesh — no firewall mods required.
6. /etc/skel/ carries veilor branding. New users get the black colour scheme, Konsole profile, and Plasma layout on first login. Test: useradd test; log in as test; KDE comes up branded, no white flash, Fira Code system font.
7. virtio-9p Anaconda log capture is active by default. test/run-vm.sh mounts a host directory into the VM; Anaconda logs land there during install. Replaces the broken virtio-serial path from earlier runs. Test: run install in VM; host-side mount has program.log, storage.log, packaging.log populated.

Free-form notes from the actual walkthrough — cosmetic glitches, slow paths, surprising behaviour — append below.

• TBD — fill in during the operator-driven VM run.

---

Action items for next release

(Empty until the test exposes something. PRs / commits opened during the run go here.)

• TBD