OS lifecycle & upgrades

A BOA host has two upgrade axes that move independently, and conflating them is the usual source of trouble:

• The BOA software — the barracuda/octopus meta-installers and everything they manage (Nginx, Percona, the PHP version set, the Ægir Master and the Octopus Satellites). This moves on a barracuda up-<tier> / octopus up-<tier> command, on a cron schedule, or on a SKYNET tag.
• The operating system — the Devuan (or Debian) base. This moves through a major-codename chain (beowulf → chimaera → daedalus → excalibur), one codename per pass, each pass a full barracuda up-<tier> system plus a reboot.

This section is the operating reference for both axes: the automated codename chain driven by run-to-*.cnf triggers, the classic explicit _${FROM}_TO_${TO}=YES path, the full up-* command matrix with its corrected per-mode semantics, and the cron-driven SELFUPGRADE machinery (_AUTO_UP_*, the ICU 7.4 intl auto-heal, the unattended kernel reboot).

Everything here is keyed to live source: the auto* codename drivers and autoupboa (aegir/tools/bin/), the barracuda/octopus dispatch and _up_mode, the OS-pairing and ICU resolver in lib/functions/system.sh.inc, and autoexcalibur's Percona gate. Where a name suggests a behaviour the code does not have, it is called out: _AUTO_VER takes lts | pro | dev (not head), the notification recipient is _MY_EMAIL (there is no _EMAIL_USER_ADM), and octopus … force is identical to both in _up_mode — it does not "honour the cnf".

The shape worth holding in mind:

• One codename advance per pass, iterative. Neither the automated nor the classic path teleports across releases. A Debian-Buster host reaches Devuan Daedalus through Beowulf and Chimaera, rebooting between each. Budget hours, not minutes, for a long chain.
• Percona gates the newest OS. Excalibur ships only Percona 8.4; autoexcalibur refuses to run (exit 1) on 8.0 or 5.7, and there is no direct 5.7 → 8.4 jump — you stage 5.7 → 8.0 → 8.4 first, on Daedalus.
• Backups are the only rescue. These chains run unattended across multiple reboots. There is no in-place rollback; recovery is "restore the VM snapshot." Every page in this section opens with that caveat for a reason.

The pages below cover the automated codename chain, the classic per-hop path, the full manual upgrade command matrix, and the cron-driven SELFUPGRADE scheduler.

See the Reference appendix for the consolidated _VAR and command tables, and Discontinued features for the dropped codename targets and retired markers.