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.

Pages

  • Automated codename upgrades — the run-to-*.cnf triggers, the four auto* codename drivers, the service clean-boa-env start launch, the Percona/ICU sequencing on the Daedalus/Excalibur path, the provider boot caveats, and the post-chain PHP-version cleanup.
  • Classic major OS upgrade — the explicit _${FROM}_TO_${TO}=YES control variables plus barracuda up-<tier> system, the full codename pairing matrix (Devuan→Devuan and Debian→Devuan/Debian), and when finer per-hop control beats the automated path.
  • Manual BOA upgrade reference — the complete barracuda up-* / octopus up-* matrix: full vs system, silent log mode, the Percona and PHP-set tokens, and the corrected octopus per-component semantics (aegir / platforms / both / force).
  • SELFUPGRADE reference — the cron-driven scheduler: the _AUTO_UP_* variable matrix and default timing, _AUTO_VER / _AUTO_PHP, the two cron-line forms autoupboa writes, the weekly ICU 7.4 intl auto-heal, and the _if_new_kernel_reboot unattended-reboot guard.

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