Updating LexiSuite
Status, 11/11/2026. In-place update is tested on image files only; it has not updated a real stick or an installed disk yet. Writing a new image remains the tested way to update.
The classic Panel's Status page shows the
version, short source commit and UTC build date of the
Panel binary currently serving the page. The same fingerprint appears in
the classic footer. A manually compiled development binary may display
commit unknown or built unknown: this is not
evidence of an approved release. /api/version provides the
longer machine-readable build identity.
Release identity
Every production release needs a new SemVer (including a newer
prerelease number, if applicable), a specific immutable source commit
and a reproducible SOURCE_DATE_EPOCH. The signed release
tools derive the UTC build date from that epoch. The release build sets
LEXIPANEL_BUILD_COMMIT, LEXIPANEL_BUILD_DATE
and their LEXISUITE_BUILD_* equivalents for the image
builder; the controlled GA11 stage also sets both. The operator must
update the workspace's [workspace.package] version and
associated locked build inputs as part of the separately reviewed source
change before cutting a release.
LX14-15's release_tool.py build requires
--previous-version LAST_APPROVED_VERSION and
--version NEW_VERSION in addition to its existing mandatory
arguments. It refuses equal, older, and build-metadata-only versions. It
also refuses to sign a manifest whose version differs from the version
compiled into the Panel crate. A dry-run can omit the previous version
for planning, but a real release cannot.
GA11's independent release builder continues to require
--previous-approved-version and strictly increasing
rollback index. The approved previous version comes from the release
authority, not from a local file the updater can modify.
Updates on an installed LexiOS A/B system
The existing Panel update page uses the privileged
lexios-update check → review/approve →
apply workflow. A downloaded release must pass its
signed-envelope, provenance, exact artifact hashes, architecture,
preservation contract and security-epoch checks before
the native appliance owner can stage an inactive image. No model,
credential or settings folder is supposed to be included in the
versioned image.
The new inactive-ESP path is opt-in and requires additional provisioning:
- Provision a securely mounted, independently verified EFI System
Partition (ESP), plus the existing root-owned native slot state,
preservation manifest, trusted release verifier, writable inactive
system-image store, and known-good recovery slot. In the updater's
trusted
applianceconfiguration, setboot_rootto the absolute ESP mount path.boot_dirremains the existing separate native record directory. Withoutboot_root, native trial publication is refused. - Build a system bundle with both slot-specific signed UKIs at
EFI/LexiOS/LEXIOS-A.efiandEFI/LexiOS/LEXIOS-B.efi. Their exact SHA-256 values must appear asuki_a_sha256anduki_b_sha256in the signedrelease.manifest. They must embed the correct slot, version, security epoch and dm-verity root hash. A legacy bundle lacking either digest is not an in-place-bootable update. - Keep the currently-good UKI and the systemd-boot managed stable
entry in the ESP. The inactive UKI and entire bundle are independently
hashed and checked against the authenticated manifest. The appliance
copies only the inactive slot's UKI, verifies its readback, writes the
native pending slot and one-attempt boot record, and publishes a
boot-counted candidate entry. The stable entry and active UKI are not
overwritten.
lexios-updatechecks the native records and the installed candidate entry before reporting that the trial is armed. - Reboot using the installed boot manager. The trial entry is allowed one attempt. A failed or unconfirmed attempt must go back to the original known-good slot; a good attempt may only be promoted after the independently authenticated boot attempt, measured-root evidence and monotonic rollback-floor reconciliation. Ordinary unsigned status strings, bootloader files or HTTP service health are not sufficient promotion evidence.
Current qualification limit: Native image staging and ESP candidate publication are not the same as a fully qualified in-place upgrade. The privileged CLI's authenticated post-boot binding deliberately still refuses when the independent firmware/TPM protected-attempt producer is unavailable. Full good/bad/no-marker reconciliation, and actual loop-partition tests covering single-kernel and dual-kernel sticks and installed disks, require that producer and a real offline Rust build/test environment. Do not deploy the new ESP trial path to a production stick or disk until those checks have passed on sacrificial media. Secure Boot itself must authenticate the enrolled signer of the booted UKI; a PE certificate-table check alone is not Secure Boot verification.
Windows, macOS and ordinary Linux
The portable LEXISUITE FAT volume's native installers
are separate from the privileged LexiOS A/B updater. Updating the
Panel/Engine applications on those host operating systems must preserve
their data and their installed service manager; it must not try to write
the machine's ESP using LexiOS slot commands. The Windows/macOS
source-port contract and its validation are not part of this packet's
implemented/tested result. Plain-Linux release-pointer updates retain
their existing independently validated backup and health-reconciliation
path.
Diagnosing a refused update
Use the Panel status and update details or the administrator's
lexios-update --config /etc/lexios/update.json status
command. A refusal for an unprovisioned ESP, missing signed UKIs, a
mismatched root hash, an interrupted trial or unavailable protected boot
authority means do not force confirmation. Retain the
last known-good boot image and the updater journal, inspect the original
signed candidate and mounted boot layout, and complete authenticated
reconciliation before retrying.