@@ -161,16 +161,28 @@ mode of drift here is a TLS error nobody expects.
 {{- if and $existing (hasKey $existing "data") (hasKey $existing.data "tls.crt") (hasKey $existing.data "tls.key") -}}
 {{- dict "cert" (index $existing.data "tls.crt" | b64dec) "key" (index $existing.data "tls.key" | b64dec) "serverName" $serverName | toYaml -}}
 {{- else -}}
-{{- /* EC, and not by preference. VyOS stores a private key as bare base64 and
-       rebuilds the PEM itself on read (vyos/pki.py load_private_key), trying
-       exactly two armours: PKCS#8 `PRIVATE KEY` and SEC1 `EC PRIVATE KEY`.
-       sprig's genSelfSignedCert is RSA and emits PKCS#1 `RSA PRIVATE KEY`, which
-       neither wrap parses, so the commit dies at src/conf_mode/pki.py with
-       "Invalid private key on certificate" and the gateway boots with no
-       configuration at all. Measured on a real appliance boot, not deduced.
-       genPrivateKey "ecdsa" emits SEC1, which is the second armour VyOS tries,
-       and genSelfSignedCertWithKey issues a matching certificate for it. */ -}}
-{{- $key := genPrivateKey "ecdsa" -}}
+{{- /* Ed25519, and the reason is the format rather than the curve. VyOS stores
+       a private key as bare base64 and rebuilds the PEM itself on read
+       (vyos/pki.py wrap_private_key), and on the SHIPPED 2026.03 image that
+       function has exactly one armour: PKCS#8 `-----BEGIN PRIVATE KEY-----`.
+       Anything else fails load_private_key, conf_mode/pki.py raises "Invalid
+       private key on certificate", and the gateway boots with no configuration
+       at all.
+
+       sprig gives one generator that emits PKCS#8, and this is it. genPrivateKey
+       "rsa" emits PKCS#1 and genPrivateKey "ecdsa" emits SEC1; both are rejected,
+       and both have been shipped here and failed a real boot.
+
+       Two earlier revisions of this comment cited a two-armour PKCS#8-or-SEC1
+       loop as measured fact. That loop is real but lives on vyos-1x `rolling`,
+       which is six months ahead of this image — and it was read from a URL
+       naming a branch that does not exist (`.../vyos-1x/current/...`), which
+       GitHub silently serves from the default branch. Check upstream behaviour
+       against a ref that resolves, or against the image itself.
+
+       PKCS#8 is also the first armour tried on `rolling`, so this choice holds
+       whichever version the appliance ends up carrying. */ -}}
+{{- $key := genPrivateKey "ed25519" -}}
 {{- $gen := genSelfSignedCertWithKey $serverName nil (list $serverName) 3650 $key -}}
 {{- dict "cert" $gen.Cert "key" $key "serverName" $serverName | toYaml -}}
 {{- end -}}
@@ -326,6 +338,17 @@ lockstep with the pinned image. This is the strongest form of the
 the whole config.boot, not just a seed, now lives beside the image. When the
 image bumps, re-capture config.boot from the new image's `save`.
 
+KNOWN DRIFT, do not read the footer as authoritative: it is missing at least
+three components the 2026.03 image declares, so the version map here and the
+image's own do not match and `migration_needed()` is true on every boot. The
+practical effect is small, because VyOS prunes footer entries the system does
+not know and the seed rewrites config.boot from the NoCloud disk each boot
+anyway — but "captured verbatim" above is a claim this file no longer fully
+supports, and the fix is a re-capture from a `save` on the image rather than
+hand-editing entries in. Adding an entry by hand is specifically what NOT to
+do: a component named at a version the image does not carry is how a migration
+gets triggered rather than avoided.
+
 WHY cloud-init at all (and not controller-only over the API): the controller's
 channel is the HTTPS REST API, which can only answer once the gateway already
 has an IP, the API running, AND this per-instance api-key installed — it cannot
@@ -533,11 +556,6 @@ system {
     }
     host-name "{{ $ctx.Release.Name }}"
     login {
-        operator-group default {
-            command-policy {
-                allow "*"
-            }
-        }
         user vyos {
             authentication {
                 encrypted-password "*"
 
@@ -360,18 +360,23 @@ tests:
   # The format of the seeded key, pinned because getting it wrong costs the whole
   # gateway and does so silently at boot rather than at render.
   #
-  # VyOS stores a private key as bare base64 and rebuilds the PEM itself on read
-  # (vyos/pki.py load_private_key), trying exactly two armours: PKCS#8 `PRIVATE
-  # KEY` and SEC1 `EC PRIVATE KEY`. sprig's genSelfSignedCert is RSA and emits
-  # PKCS#1, which neither wrap parses, so src/conf_mode/pki.py refuses the commit
-  # with "Invalid private key on certificate" and the guest comes up with no
-  # configuration at all. That shipped once and was found on a live boot, not in
-  # any test — hence this one.
-  - it: seeds an EC private key, the one shape VyOS can read back
+  # VyOS stores a private key as bare base64 and rebuilds the PEM itself on read,
+  # and on the shipped 2026.03 image wrap_private_key has exactly ONE armour:
+  # PKCS#8 `-----BEGIN PRIVATE KEY-----`. Anything else fails load_private_key,
+  # conf_mode/pki.py refuses the commit with "Invalid private key on
+  # certificate", and the guest comes up with no configuration at all.
+  #
+  # Two wrong formats have shipped here and each cost a live boot: PKCS#1 from
+  # genSelfSignedCert, then SEC1 from genPrivateKey "ecdsa". The second was
+  # chosen from a two-armour loop that exists only on vyos-1x `rolling`, read
+  # from a branch name that does not resolve. genPrivateKey "ed25519" is the one
+  # sprig generator that emits PKCS#8, and PKCS#8 is the first armour on
+  # `rolling` too, so it holds either way.
+  - it: seeds a PKCS#8 private key, the one shape this image can read back
     asserts:
       - matchRegex:
           path: stringData["tls.key"]
-          pattern: '\A-----BEGIN EC PRIVATE KEY-----'
+          pattern: '\A-----BEGIN PRIVATE KEY-----'
         documentIndex: 0
       # And it reaches config.boot as bare base64 under pki, with no armour and
       # no newlines, which is what the base64 validator on that node requires.
@@ -385,5 +390,5 @@ tests:
         documentIndex: 1
       - notMatchRegex:
           path: stringData.userdata
-          pattern: 'BEGIN (RSA |EC )?PRIVATE KEY'
+          pattern: 'BEGIN [A-Z0-9 ]*PRIVATE KEY'
         documentIndex: 1
@@ -37,11 +37,6 @@ system {
     }
     host-name "vyos"
     login {
-        operator-group default {
-            command-policy {
-                allow "*"
-            }
-        }
         user vyos {
             authentication {
                 encrypted-password "*"
 
@@ -1,15 +1,20 @@
 [Unit]
 Description=Report the VyOS configuration load result to the console
-# After, not Before: the point is to read what vyos-router left behind. It runs
-# whether that succeeded or failed, because "which line did it object to" is only
-# answerable from the log and the console is the only way off this appliance.
+# After= is a hint here and nothing more: vyos-router.service is Type=simple, so
+# systemd calls it started the instant the process forks, which happens long
+# before the configuration is loaded. The script waits on /tmp/vyos-config-status
+# the way upstream's own vyos-config init does; that is what actually orders it.
 After=vyos-router.service
 Wants=vyos-router.service
 
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=/usr/local/sbin/vyos-appliance-config-report.sh
+# The script bounds its own wait at 240s and always exits 0. This is the backstop
+# for a hang inside journalctl, and it is longer than that wait so a timeout here
+# means something other than the wait went wrong.
+TimeoutStartSec=300
 
 [Install]
 WantedBy=vyos.target
@@ -1,32 +1,62 @@
 #!/bin/sh
-# Print why the configuration failed, to the console, after vyos-router has tried
-# to load it.
+# Say what vyos-router made of the configuration, on the console.
 #
-# vyos-router reports a rejected config.boot as the single line "Configuration
-# error" and puts the reason in /var/log/vyatta/vyos-config.log inside the guest.
-# On this appliance nothing can go and read that: there is no SSH service, the
-# `vyos` login is locked, and the bootloader is password-protected, so the
-# console is the only channel and it carries the one useless line. The bring-up
-# emitter does not help either, because it is installed by the configuration that
-# just failed to load.
+# A rejected config.boot reaches the console as the single line "Configuration
+# error". On this appliance nothing can go and read the reason: there is no SSH
+# service, the `vyos` login is locked, and the bootloader is password-protected.
+# The bring-up emitter does not help either, because cron installs it from the
+# configuration that just failed to load. So the console is the only channel and
+# it carries one useless line.
 #
-# So this runs after vyos-router regardless of outcome and puts the tail on the
-# console, where logSerialConsole and the e2e collector already pick it up. It is
-# a few lines on a successful boot and the whole answer on a failed one.
+# WHERE THE REASON ACTUALLY IS. Not in a file. vyos-boot-config-loader.py catches
+# ConfigSessionError, writes the status file and exits before the block that
+# writes its own log, so that log exists only on success. What does persist is
+# the journal: conf_mode/pki.py and conf_mode/service_https.py are both dispatched
+# through vyos-configd, which logs the ConfigError it caught. That is readable
+# today with no kernel argument and no image debug flag.
+#
+# WHY IT POLLS. vyos-router.service is Type=simple, so systemd treats it as
+# started the moment the process forks and an `After=` on it is satisfied long
+# before the configuration is loaded — measured: an earlier revision of this
+# script printed its line at boot and the "Configuration error" arrived seconds
+# later. Waiting on the status file is what upstream's own vyos-config init does.
 set -u
 
-LOG=/var/log/vyatta/vyos-config.log
-MAX=25
+STATUS_FILE=/tmp/vyos-config-status
+WAIT=240
+MAX=40
 
 log() { echo "vyos-appliance-config-report: $*" > /dev/console 2>&1; }
 
-if [ ! -s "$LOG" ]; then
-    log "no $LOG; vyos-router either did not run or wrote nothing"
+dump() {
+    # -o cat drops the syslog preamble; the message is the whole point and the
+    # console is narrow.
+    journalctl -b -u "$1" -p err --no-pager -o cat 2>/dev/null | tail -n "$MAX" \
+        | while IFS= read -r line; do
+            [ -n "$line" ] && log "| $1: $line"
+        done
+}
+
+i=0
+while [ ! -f "$STATUS_FILE" ] && [ "$i" -lt "$WAIT" ]; do
+    i=$((i + 1))
+    sleep 1
+done
+
+if [ ! -f "$STATUS_FILE" ]; then
+    log "no $STATUS_FILE after ${WAIT}s; the config loader never reported. Journal follows."
+    dump vyos-configd
+    dump vyos-router
     exit 0
 fi
 
-log "last $MAX lines of $LOG:"
-tail -n "$MAX" "$LOG" 2>/dev/null | while IFS= read -r line; do
-    log "| $line"
-done
+status="$(cat "$STATUS_FILE" 2>/dev/null | tr -d '[:space:]')"
+if [ "$status" = "0" ]; then
+    log "configuration loaded and committed"
+    exit 0
+fi
+
+log "configuration REJECTED (status ${status:-unknown}); reason follows"
+dump vyos-configd
+dump vyos-router
 exit 0