LexiSuite Docs

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:

  1. 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 appliance configuration, set boot_root to the absolute ESP mount path. boot_dir remains the existing separate native record directory. Without boot_root, native trial publication is refused.
  2. Build a system bundle with both slot-specific signed UKIs at EFI/LexiOS/LEXIOS-A.efi and EFI/LexiOS/LEXIOS-B.efi. Their exact SHA-256 values must appear as uki_a_sha256 and uki_b_sha256 in the signed release.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.
  3. 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-update checks the native records and the installed candidate entry before reporting that the trial is armed.
  4. 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.