CluPilotCloud/docs
nexxo 0b26e45147 Install Proxmox the way Proxmox says to, not the way I guessed
The previous commit put installimage with a Proxmox image into Task 3. That
image does not exist. Hetzner's installimage carries no Proxmox and lists it as
unsupported, so anyone following that instruction finds only Debian and ends up
back at the intermediate base system the same commit had just removed. Looked
up rather than remembered, which is what should have happened before writing it
down.

The mechanism the owner described does exist and is the official one since PVE
8.2: build the real Proxmox ISO with an embedded answer file via
proxmox-auto-install-assistant, run it under QEMU against the physical disks
from the rescue system, reboot into a finished node. Hetzner publishes a
tutorial for exactly this. No Debian, no VNC, no click — which is what the
owner said in the first place.

Two things fall out of the answer file that improve the plan.

The hand-written systemd resume service is gone. [first-boot] with
source = "from-iso" is the supported way to have the script pick itself up
after the reboot, and it is the only variant that can work before the tunnel
exists — a from-url hook would be pointing at a CluPilot it cannot reach yet.
The carry-across of the progress file stays necessary regardless: the rescue
system's copy still lives in RAM.

Trap 2 was being applied to the wrong machine. "Root partition last, not on
LVM" comes from the template traps, and the reason it exists is
GrowGuestFilesystem, which grows a GUEST filesystem. The template is built in
Task 8 from a Debian cloud image, not from the host's own layout, so the
justification written into Task 3 ("it applies to the host too, because the
template is built from here") does not hold. It remains binding for the
template, where it belongs. The host gets ZFS, and that it happens to involve
no LVM is a side effect rather than the reason — with arc-max pinned, because
the default takes half the RAM a host needs for its guests.

Also recorded: the answer file needs an fqdn and a root password that the
command line does not carry. The password is generated and thrown away, because
the platform no longer logs in over SSH and the plan already says a half
installed machine is reinstalled rather than repaired — keeping a secret for an
emergency the plan does not have only creates another place a secret lives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 19:45:29 +02:00
..
design Write the handoff, and rescue the approved templates into the repo 2026-07-27 20:18:20 +02:00
handoffs Put the price recognition back, all 3526 lines of it 2026-07-30 16:35:55 +02:00
specs docs: Phase D spec — service framing, redesign & CRUD completeness 2026-07-25 14:13:23 +02:00
superpowers Install Proxmox the way Proxmox says to, not the way I guessed 2026-07-30 19:45:29 +02:00
deployment.md feat(deploy): releases you can pin to, and a version that tells the truth 2026-07-26 15:21:38 +02:00
handoff-plan-catalogue.md docs: handoff for the plan catalogue rebuild 2026-07-26 10:43:17 +02:00
monitoring-uptime-kuma.md fix(monitoring): cap monitoring retries at the run budget; dependency-free liveness probe 2026-07-25 20:19:32 +02:00
wireguard-hub.md docs(wireguard): document the ownership model and config storage 2026-07-25 22:55:14 +02:00