OS lifecycle & upgrades
The two independent upgrade axes of a BOA host: the barracuda and octopus software stack and the Devuan codename chain, plus the manual commands and cron-driven SELFUPGRADE.
A BOA host has two upgrade axes that move independently, and conflating them is the usual source of trouble:
- The BOA software — the
barracuda/octopusmeta-installers and everything they manage (Nginx, Percona, the PHP version set, the Ægir Master and the Octopus Satellites). This moves on abarracuda 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 fullbarracuda up-<tier> systemplus 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;
autoexcaliburrefuses to run (exit 1) on 8.0 or 5.7, and there is no direct5.7 → 8.4jump — you stage5.7 → 8.0 → 8.4first, 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, the cron-driven SELFUPGRADE scheduler, and the base-OS baseline a system pass maintains underneath BOA.
See the Reference appendix for the consolidated _VAR
and command tables, and Discontinued features for the
dropped codename targets and retired markers.
Automated codename upgrades
The automated Devuan codename chain: the run-to-target markers, the four auto codename drivers, Percona and ICU sequencing, provider boot caveats, and post-chain PHP cleanup.
Classic major OS upgrade
The explicit per-hop OS upgrade path: set one FROM-TO control variable, run a system pass, and walk the full Devuan and Debian codename pairing matrix one hop at a time.
Manual BOA upgrade reference
The complete barracuda and octopus upgrade command matrix: full versus system-only, silent log mode, the lts, pro and dev tiers, and the octopus per-component modes.
SELFUPGRADE reference
BOA's cron-driven upgrade scheduler: the AUTO_UP variables and default timing, the weekly system run, the ICU 7.4 intl auto-heal, the unattended kernel-reboot guard, and the service-teardown markers autoupboa honours on every pass.
Host OS baseline
The base-OS choices a barracuda pass makes for you: the rsyslog daemon it always installs and never removes, whether BOA starts or reloads the cron service, the decorative root login banner and its packages, and which OpenSSL series BOA's own SSL toolchain (and Nginx) tracks.