HiveStation V22 - answer files, a live image of its own, and five languages
V22 is out, on GitLab: download
HIVESTATION-V22.33.26.tar.gz from
https://gitlab.com/aureladmin/hivestation/-/releases/V22.33.26. Existing installs move up with
hivestation-upgrade.sh as usual - Btrfs, LVM and ZFS roots, V15 onwards. The disk layouts, the boot chains and what lands on the target are unchanged from V21; what changed is how you drive an install.
Install from an answer file. Every question of S1 to S8, of the desktop layout script and of the upgrade tool now goes through one funnel: the value comes from an answer file, else the question is asked, else the script default applies. The file is plain
key=value, parsed and never executed - a line that is neither a comment nor a pair rejects the whole file. Two modes:
assist, where a missing key falls back to the question, and
strict, where a missing or invalid key stops before anything is done and names the exact key. Keys are semantic (
disk_mode=raid1,
wan_iface=ens18,
disk1=/dev/disk/by-id/...), so one file carries from one machine to the next; you point at it with
--preseed <path|URL>, with
$HS_PRESEED, or by machine identifier in a directory - serials first, then the first NIC MAC, then
default.conf. In this mode S1 refuses to touch a disk without an explicit
wipe_disks=oui, and any key that no step ever consumed is reported at the end - fatal in strict on both routes. Until 22.33.20 the single-pass install only warned: a typo in a fleet answer file went through and the deployment carried on, which is the one case strict exists to stop. Ready-made files are in
preseed-examples/<lang>/: seven profiles, in five languages. Only the comments differ between the language directories - every key and value is identical apart from
lang_code and
timezone - and a self-test compares the five sets line by line, so a key added in one language and forgotten in another cannot ship.
One questionnaire, one reboot. S0 collects the decisions of the whole chain up front and checks each answer as you type it. S1 then lays the suite and the answer file down in the target and plays S3.1 -> S3.2 -> S4 -> S5 -> S7 -> S8 inside it: state kept on disk, one log per step, a bounded timeout per step, a hard stop on failure, and
--reprendre to restart at the first unfinished step. A machine that used to need seven sessions at a keyboard now needs none. The step-by-step route still works exactly as it did.
A live image of its own. tools/hivestation-live-build.sh builds a live image that runs the Proxmox kernel, and
tools/hivestation-iso-build.sh refreshes an already-built one in seconds with the current tree and, optionally, an answer file. No prebuilt ISO is shipped - you build it from the archive you can read. Because the image runs the PVE kernel, its
zfs module is signed with that kernel and needs no DKMS build in the live session, so
zpool works there even under Secure Boot. The image carries a graphical front end over the same scripts, for people who would rather click than read a terminal.
Five languages. French, English, German, Spanish and Portuguese, from the first question to the last line of the upgrade report - the journal included, so
journalctl -t hivestation speaks the installed language. The boot screens follow: Plymouth and the GRUB theme are static files, so their strings are substituted from a per-language catalogue when the theme is laid down - the project's own name and the titles that identify it stay in English everywhere, as they should. The keyboard layout you choose is honoured where it matters - at the Plymouth LUKS prompt and at the ZFSBootMenu prompt. The ZFSBootMenu prompt also names the layout it loaded, so you know before you type.
Two fixes worth naming, both found installing over a machine that had already been served. An encrypted LVM install dropped to the rescue shell on first boot: both disks carried a Btrfs volume labelled
HIVBOOT - the new one and the leftover - and
/boot was resolved by label with a
head -1. It now comes from the volume actually mounted on the target, and the label fallback refuses when two distinct filesystems carry it. Separately, upgrading a ZFS node that had never received the Proxmox repository purged the
zfs-dkms stack toward packages it could not install, leaving an initramfs with no ZFS in it; the node would not boot. The migration now lays the repository itself before touching the stack, and reads the regenerated initramfs back to check ZFS is in it before calling the step a success.
The code reads in English now. The suite is meant to be read and audited
before it is run, so its comments are no longer written only in French: its
12 101 French comment lines were moved to English, the language of the
guide. Behaviour is unchanged - not one line of code moved, and a self-test
proves it file by file.
Disk alerts and guided replacement speak the node's language. On a German
desktop the degraded-mirror dialog came out in French and English next to a
correctly translated notification, and the guided replacement run from a
terminal mixed German and bilingual lines. Those messages never went through
the catalogue. In 22.33.2 the two alert scripts and both
auto-replace-*-disk.sh
do - every message, the LUKS passphrase prompt and the disk-name confirmation
included - with 95 new keys in German, Spanish and Portuguese. A yes/no
question that showed a French default next to a translated legend now takes
its default from the legend itself. The upgrade tool now re-lays the Btrfs
HA pair as it did the ZFS one, and lays the catalogues where the library reads
them first - the suite tree of the node - so a node upgraded in place gets the
fix too (22.33.3).
The desktop said the array was healthy while a disk was missing. On an
amputated Btrfs mirror the array indicator stayed green and read "healthy",
directly above a red "Health: degraded" line - two indicators side by side, two
sources, and the green one was wrong. The collector walked
/sys/fs/btrfs/<uuid>/devices/ and only flagged a member as missing when its
block node had disappeared; a disk that is genuinely pulled leaves that list
altogether, so the loop never saw it and the count stayed at zero. It counted
what is PRESENT, never what is EXPECTED. It now derives the count from
devinfo/, which is indexed by numeric devid, keeps the entry of an absent
member with its
missing flag, and is readable without privilege - so no new
verb on the broker. Absent members are listed under their devid, since they no
longer have a device name, and the old counting is kept as a fallback where the
kernel does not expose
devinfo. The rendering already painted a missing member
red: only the counting was blind. Widget v27 -> v28 at the time; it ships at v30.
Same bench, a finding with no fix attached: on an encrypted install the swap
disappears with its disk and the SWAP1 -> SWAP2 failover does not play.
swap-failover is not enabled when the swap is encrypted:
crypttab and
nofail handle it, and SWAP2 stays a reserved partition. S1 says
so to the operator and a bench requires it.
The themes and the widget stopped being laid down at all. From 22.33.5 the
Plymouth theme, then the GRUB theme, then the widget were shipped as directories
instead of tarballs, so that the repository's own checks could read inside them.
S1 copies the suite into the target from an explicit list, and the entry that
carried them was
*.tar.gz - which matches no directory. Three shipped versions
therefore installed none of the three, and S8 returned a failure on every
install that asked for them. The list now names the directories, and a bench
compares what S1 lays down against what the archive carries, component by
component, so a component added to the archive and forgotten in the copy list
cannot ship again.
Three places where a state was decided by reading prose. A degraded
mirror, a cancelled ESP synchronisation and, on the desktop panel, a node that
was perfectly healthy: three symptoms, one cause. Each state was decided by
reading the PROSE of a log - words like "ERREUR" or "missing" - or a completion
marker that was also written when the operation had failed. Prose is translated,
so nothing matched on a German or Portuguese node and the fallback displayed
"active"; and a marker written on both outcomes says nothing. Every backend now
writes an ASCII verdict of its own, from a trap so that a cancelled run still
writes one, and the monitor reads that alone. The panel's own indicator was
counting the disks PRESENT rather than the disks EXPECTED, which is why a pulled
disk left the count at zero.
Error paths speak the installed language. The V22.33.4 notes said this was
not covered: the refusal paths of the shared libraries still came out in French
whatever the install language. The cause was mechanical - those messages were
built with their value already inside the string, so they matched no catalogue
entry and fell through to the French original. 306 calls now pass a template and
its values separately, and 166 new templates went into the five catalogues. What
remains is named rather than rounded off: 163 calls still build their text with
the value already inside, across ten libraries, and those keep the bilingual
French/English form. A bench counts them with a ceiling that only goes down.
Translated interfaces were losing information. Three defects of the same
family. On an English menu the option numbers were gone, because the English
catalogue entry had replaced the numbered French line and taken the number with
it - two components out of seven were selectable by the number shown. English
messages had lost their
%s, so a reader saw "failed" without being told what
failed, and the confirmation that asks you to type the exact name of a disk to
be erased no longer showed that name. And three untranslated entries reached
non-French installs verbatim. Each of the three now has a check that counts the
sites and refuses to grow.
What was validated, and what was not. On real hardware, driven by an answer file: five disk modes, each driven in a different language, every one installed over an already-occupied target, chain green end to end, reboot verified. Seven modes out of seven through the graphical route. Upgrade V21 -> V22 on real hardware in ZFS mirror and Btrfs RAID1. Those figures date from the 22.33.4 series and are unchanged.
The fixes listed above were exercised since, in virtual machines rather than on metal: four installs carried to the end on both routes - from the archive in a live session and from the project's own image - in French, German and Spanish, across a ZFS mirror and encrypted Btrfs RAID1. Each one ends on the installer's own exit code, hands back the seven step logs written into the target, and was then booted from disk: unlock prompt and desktop session both come up in the installed language. Strict mode on a single-pass install was proven in both directions - a deployment that must stop does stop, one that must go through does - on all five disk families, the encrypted ZFS mirror included. Hibernation keeps its EXPERIMENTAL flag and stays firmware-dependent. Encrypted installs keep the ESP and
/boot in cleartext: with Secure Boot off, TPM auto-unlock does not stop someone with brief physical access from planting a modified initramfs - only the passphrase does. The LVM run proved the mode itself but does not attest Secure Boot or TPM 2.0 - those come from the Btrfs runs.
HiveStation is under the
GNU AGPL v3 - the same licence as Proxmox VE. Use it, change it, pass it on; just pass the source and the same freedoms on with it. The archive carries
LICENSE, plus
LICENCE-FONTS.txt for the Ubuntu Mono files embedded in the GRUB theme.
The full guide is in the archive (
HIVESTATION-V22-GUIDE-EN.md), per-version detail in its §8.1, and the development journal in
DEVLOG-V22.md.
)