Updates (planned)

FAQ › EUZOS Desktop › Updates · Nederlands

Status: planned. Automatic version updates are a design (docs/UPDATES.md, 27-10-2026), not built yet. Nothing on a PC or server asks for or installs a new OS release by itself today. The commands, files and endpoints on this page marked planned do not exist in the code yet. What already works is the manual trial/commit cycle (see Boot).

What is it?

The plan describes how a running EUZOS PC (Desktop) or server (Server) learns about a newer release, downloads it, and installs it without the risk of a machine that no longer boots. It reuses parts that already exist: the trial kernel (try/commit), signed files and anti-rollback (FETCH.TXT), the signed release manifest, the download server with download tokens, and the app catalogue.

How do I…?

How do I update EUZOS today?

By hand, with parts that exist now:

New kernel: put it on the boot volume as \EOS\KX64TRY.ELF, run try, check it, then commit (the Mac script tools/trial.sh automates this over SSH). See Boot.
A signed file: fetch <url> <path>.
Everything: reinstall with the Installer (this wipes the disk, including the profiles).
Chromium: apps install chromium by hand fetches a newer version from the catalogue (see Desktop and apps).

How will a PC learn about an update? (planned)

A desktop asks the profile server right after a successful login (it needs the PC token), then every 4 hours plus a random 0–30 minutes while someone is logged in; never more than once per 15 minutes. The channel follows the build type: a production build only takes production builds, a test build only test builds.

What will the user see? (planned)

A yellow label "Update available" next to the taskbar, on every desktop screen; tapping it opens the update card with the release notes, Restart now and Tonight.
Tonight: at 03:00 local time if the PC is on, idle for 15 minutes and on mains power or above 40% battery; if the PC is off, the next shutdown arms the update ("Update and shut down").
Security updates: "Required before <date>"; after the deadline a 15-minute countdown, then the restart. The deadline counts from when this device first saw the offer.
Afterwards one notification: "EUZOS was updated to 240", or after a rollback "The update could not be installed; EUZOS kept version 239".

The owner's decision: on the desktop, download and staging are automatic; an organisation can choose "ask" as policy.

(The screen texts above come from the design; they are not in the translation files yet.)

How will it install safely? (planned)

Check the signed release descriptor and the manifest (signature, edition, build type, build higher than the running one, version not lower than in FETCH.TXT, not revoked).
Stage: only changed files (delta by SHA-256) go to \EOS\UPD\; the new kernel straight to \EOS\KX64TRY.ELF.
Restart into the trial (write TRY.TXT).
Health check in the trial kernel (within 5 minutes): a network link with an address, and TLS to the environment's profile server returning the built-in server key.
Pass: automatic commit, then the staged files into place (old ones kept in \EOS\PREV\), the new manifest, FETCH.TXT, config migrations.
Fail: the trial kernel reboots by itself; the committed kernel comes back, sees the failed trial, and gives up on that release after 2 attempts.
Report the result to the profile server.

Only the kernel is trial-booted. A release that changes the boot loader is never installed automatically in phase 1. Development kernels (build ID not starting with release-) and stick-booted systems only show the offer.

Can I go back after an update? (planned)

update rollback will swap KX64OLD.ELF back (a local swap, no download).

What about EUZOS Server? (planned)

A server never reboots on its own. Download and staging happen automatically; Server Admin gets the actions update-status, update-now and update-window <day hh:mm-hh:mm>|off. An overdue server shows red in Server Admin and on the admin page. See Server Admin.

What happens offline? (planned)

No offer and no download without the profile server. A staged release is not trial-booted while the profile server is unreachable. Over a metered (mobile) connection the PC checks but does not download ("Waiting for Wi-Fi or cable"). Offline login is not affected.

Details

Parts that already exist

Part	Where
Trial kernel and commit	`boot/src/main.rs` (`try_once`), `kernel::boot_volume` (`prepare_try`, `commit`), `tools/trial.sh`
Self-recovery of a trial kernel	panic handler, fatal exception, `kernel::watchdog` (`HANG.TXT`)
Signed files, anti-rollback	`tools/sign`, `kernel::fetch`, `\EOS\FW\SIGNPUB.TXT`, `\EOS\FW\FETCH.TXT`
Release manifest	`libs/manifest`, `tools/release.sh`, `tools/stickrelease.sh`
Build numbers	`OS_BUILD` (Desktop), `SERVER_BUILD` (Server), the edition mark `EUZOS-EDITION:` in the kernel file
Download server and tokens	`server/download`, `POST /api/apps/token`, `POST /api/workplace/v1/download-token`
App catalogue	`server/profile/src/apps.rs`, `kernel/src/app_store.rs`

Build plan (from docs/UPDATES.md)

Phase	What
U1	release format (`DESKTOP.REL`/`SERVER.REL`, `.RVK`), `libs/release`, `release.sh` per edition
U2	profile server: schema 19, offer/token/report, rings, CLI
U3	kernel engine `kernel/src/update.rs`, console `update`
U4	desktop UX (label, card, tonight, deadline)
U5	server (`update-*` actions, signed window)
U6	admin page "Releases"
U7	apps: minimum version, automatic app updates
U8	later: key roll, A/B boot loader, release cache, Secure Boot track

Reference

Console commands

Command	Arguments	What it does	Status
`try`, `commit`	–	trial kernel once, then make it permanent	exists (Boot)
`fetch`	`<url> <path>`	signed file to the boot volume	exists
`apps install chromium`	–	fetch Chromium (newer version) from the catalogue	exists (Desktop and apps)
`update`	–	status	planned
`update check`	–	ask for an offer now	planned
`update now`	–	install now (restart into the trial)	planned
`update tonight`	–	install tonight	planned
`update rollback`	–	swap `KX64OLD.ELF` back	planned

The planned update command is English only (no Dutch alias).

Functions and modules

Module	Role	Status
`kernel::boot_volume::prepare_try`, `commit`	trial and commit	exists
`kernel::fetch::fetch_manifest`, `fetch_entry`	fetch and check a manifest and its files	exists
`kernel/src/update.rs`	update engine	planned
`libs/release`	descriptor and revocation list parsing	planned

Config files (planned)

File	Key	Values	Meaning
`\EOS\FW\UPDATE.TXT`	`device`	32 hex	random device id, made once
	`state`	`idle`, `downloading`, `staged`, `trial`, `failed`	update state
	`release`	`<edition> <build> <signature version>`	release being installed
	`staged-at`	Unix time
	`attempts`	number	trial attempts
	`apply`	`now`, `tonight`, `next-start`, `window`	when to install
	`deadline`	Unix time or `-`	security deadline
	`last-result`	e.g. `installed 240 <unix>`
	`config-schema`	number	config migration level
	`window` (server)	e.g. `sun 02:00-04:00`	maintenance window; the file is then signed with the server's own key
`\EOS\UPD\`, `\EOS\PREV\`	–	–	staged files, previous files

API endpoints (planned)

Line format (key=value) like the existing EUZOS API.

Method and path	Request	Answer
`GET /api/update/v1/offer`	`token`, `edition`, `build`, `version`, `arch`, `device`, `lang`	`none`, or `available` + `edition=`, `build=`, `version=`, `descriptor=`, `size=`, `security=`, `deadline=`, `minimum=`, `note=` lines, `revoked=`
`POST /api/update/v1/token`	`token`; body `edition=`, `version=`	an `ezdl1` download token (`token=`, `expires=`, `duration=`)
`POST /api/update/v1/report`	`token`; body `device=`, `edition=`, `from=`, `to=`, `result=installed\|rolled-back\|failed\|deferred`, `reason=`, `detail=`	`ok`
`GET /api/workplace/v1/update-offer`	workplace token	as `offer`, edition `server`
`POST /api/workplace/v1/update-report`	workplace token	as `report`

Protocol messages and formats (planned)

Release descriptor DESKTOP.REL / SERVER.REL (signed with tools/sign under exactly that name):

EUZOS-RELEASE 1
edition=desktop
build=240
build-type=production
arch=x86_64
arch=aarch64
manifest-sha256=<64 hex>
manifest-version=<signature version of MANIFEST.TXT>
minimum-from=232
config-schema=3
bootloader=unchanged
security=0

Download layout (content-addressed): download.euzos.eu/<edition>/<signature version>/ with DESKTOP.REL(.sig), MANIFEST.TXT(.sig) and one file per SHA-256. A revocation list DESKTOP.RVK / SERVER.RVK is signed by the owner.