From 820fbd43532afc58230db3bafed910b2404f5e5b Mon Sep 17 00:00:00 2001 From: Michal Date: Tue, 11 Aug 2026 15:36:58 +0100 Subject: [PATCH] docs(bastion): state the rescue-SSH evidence at its actual strength The previous wording claimed the failure was "reproduced on x86_64", which overstates it. The aarch64 observation is direct -- port 22 probed for 30 minutes with the Anaconda environment demonstrably up. The x86_64 run only shows SSH not becoming available inside a 15-minute budget; that VM was never observed reaching the rescue environment, because vitest's reporter discards the streamed log. The distinction decides where the next person looks, so it should not rest on an inference presented as an observation. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015nRFZXpKwUVE4SRSHw6GjF --- bastion/docs/ARCHITECTURE.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/bastion/docs/ARCHITECTURE.md b/bastion/docs/ARCHITECTURE.md index 4babe11..048b244 100644 --- a/bastion/docs/ARCHITECTURE.md +++ b/bastion/docs/ARCHITECTURE.md @@ -485,12 +485,20 @@ Hardcoded `/dev/sda` default broke NVMe-only machines. Fix: default to empty str integration coverage for `provision debug` (`tests/integration/pxe-rescue.test.ts`) showed the rescue environment coming up correctly — the bastion serves the kernel and initrd, Anaconda boots, fetches `debug.ks`, and reaches its installer environment — but **nothing ever listens on -port 22**. Confirmed on aarch64 by probing the port for 30 minutes while the Anaconda environment -was demonstrably running (NetworkManager, polkitd, rsyslog all up), and reproduced on x86_64 with -KVM, so it is not architecture-specific and not an emulation artefact. +port 22**. -This is orthogonal to the multi-architecture work: the same failure occurs on x86_64, which that -work does not touch. Leads worth checking, in order: +Strength of the evidence, stated precisely because it decides where to look next: +- **aarch64 — direct.** Port 22 probed every 20s for 30 minutes while the Anaconda installer + environment was demonstrably running (NetworkManager, polkitd, rsyslog on the console). Never + opened. +- **x86_64 — corroborating, not conclusive.** One clean KVM run (943s) where SSH never became + available inside a 15-minute budget. That VM's progress into the rescue environment was *not* + observed — vitest's final reporter discards the streamed log — so it is consistent with the + aarch64 result but does not independently prove it. Re-run with `KEEP_VM=1` and probe port 22 + directly to settle it. + +If the x86_64 result holds up, this is orthogonal to the multi-architecture work, since x86_64 is +untouched by it. Leads worth checking, in order: - Does `inst.sshd` actually start `sshd` in `inst.rescue` mode, or only in install mode? The port never opens, so this is the prime suspect — an auth problem would still show an open port. - `sshkey` may apply only to the *installed* system, leaving the installer environment