memory: snapshot — 2026-10-03 ~1440 (nh3-pve clean on 9, RustDesk 1.1.16, esh-nas-pve PVE 9 assessed)

2026-10-03 15:23:19 -07:00
parent d4675f2cb5
commit 5f8a1311a5
3 changed files with 20 additions and 25 deletions
@@ -39,6 +39,16 @@ Quorum: 2 nodes × 1 vote, no QDevice, no `two_node`.
 3. **`pve8to9` FAIL on both nodes:** the `systemd-boot` meta-package is installed. Both nodes boot
   via GRUB, so remove it (`apt remove systemd-boot`; `systemd-boot-efi` stays).

+## esh-nas-pve facts re-read 2026-10-03 (Prime asked whether infra-ops can upgrade it unattended)
+
+- **QNAP hardware** (`QNAP Systems, Inc.`, Comet Lake HECI present, but no AMT/IPMI we can use), so there is **no remote console**.
+- PVE 8.4.20, but still running kernel **6.8.12-13**, up since **2026-08-18**. Its first reboot in ~7 weeks is itself a risk:
+  do a **reboot test on PVE 8 first**, so a reboot problem is not mistaken for an upgrade problem.
+- **No NIC pins** (`/etc/systemd/network/` is empty); the uplink is `enp5s0f0`. Pin before the upgrade.
+- No DKMS on this node (the NVIDIA headers lesson applies to `pve`, not here).
+- Infra-ops can do the prep remotely. The upgrade reboot should happen only with someone able to reach ESH, or with
+  Prime's explicit acceptance that a failed boot means an outage until someone is on site.
+
 ## Pre-flight (no guest downtime)

 1. **Backups:** one-off `vzdump` of **all ten** guests to pbs-ana in snapshot mode, right before the