Persistence and updates
The root filesystem is RAM, rebuilt from the boot media every boot: a clean boot is always one reboot away. Three things survive:
| the saved state | /etc and the identities: pipe, SSH, the sealed vault, users. Saved every 15 minutes and at shutdown; Save state to boot media now under System, or pipeos save, on demand |
/data | an ordinary ext4 partition: repos, agent memory and transcripts, uploads, user homes, backups. It is finite; the Overview disk tile is watching it |
| packages | pipeos pkg add fetches a package and its dependencies into the local mirror on the media, so the next boot has it without a network. A plain apk add is gone at reboot |
Anything else, a file in /tmp or a hand-edited system file, evaporates at reboot. A change that must stick belongs in /data or goes through the dashboard, which saves what it changes.
The hot set in RAM
The paths that churn (logs, the network roster, the usage ledger, the schedule state) live in RAM and are flushed to /data hourly, before every save and at shutdown. A power loss costs what landed since the last flush: at most an hour of logs, a roster that rediscovers itself in ten seconds, a ledger the next ingest re-derives, a schedule state whose worst case is one job firing twice in the same minute. pipeos work park flushes and remounts /data read-only so an idle stick takes no writes; a busy Machine stays writable.
Automatic updates
Every hour the Machine checks the release origin on GitHub Releases. When something is newer:
| a new image | fetched and verified, applied in place with this Machine's identity merged in, and the box reboots. The next boot report says this boot is a self-applied image update. It waits, and retries next hour, while a job or a terminal session is live |
| new packages | the signed repository is fetched and verified, swapped onto the media atomically, installed, saved and verified again; if the verify fails the Machine rolls back on its own |
System → update automatically is the switch for the image half; off, packages still update and a newer image waits for Update now or pipeos flash apply. On a cluster a member does not apply while another is mid-update or not green. The self-check warns when the origin has never applied, is more than fourteen days stale, or last errored. The Updates view keeps the history.
Known-good, and the fence after a flash
The media holds two copies of the saved state. The canonical one boots; pipeos save writes it so that it exists at every instant except inside a single rename, so a power cut mid-save cannot leave the box without an identity. The known-good one is the last state that booted with nothing critical, promoted after every healthy boot (warnings do not block it); pipeos rollback known-good stages it for the next boot.
After a flash, by hand or by the hourly update, saves are fenced until the reboot: RAM is still the old system, and a save would re-package it over the merged state. pipeos status says NEW IMAGE APPLIED; reboot.
Operating it
The resident agent cannot run these. pipeos verify should pass before and after anything that touches the media.
| pipeos status · verify · diff | health and persistence state; will a reboot reproduce this state (non-zero means no); what changed since the last save |
| pipeos save | commit state now, guarded and atomic |
| pipeos pkg add · del | install or remove software persistently |
| pipeos snapshot ls · rollback | the saved generations on the media; stage an older one, or known-good, for the next boot |
| pipeos selfupdate | run the hourly update now; selfupdate image off|on is the System switch |
| pipeos flash check · fetch · apply · restore-identity | a newer image, in place or onto a spare disk; an identity bundle for the next boot. The live disk |
| pipeos restore-work · backup | /data back from a backup or an old stick; identity and data onto an external drive. Recovery |
| pipeos unclaim | nobody's box again; reboots into the wizard |
| pipeos wake · watchdog | a magic packet to a Machine this box has seen; the hardware watchdog. Hardware notes |
| pipeos usage · schedule | the ledger and the caps; the jobs. Schedule and usage |
| pipeos vault · secrets | the sealed store; the recovery phrase and the agent's request door. Secrets |
| pipeos cluster | membership, the page, reboot-all, services across members, agent placement. The cluster |
| pipeos work status · flush · park · unpark | the hot set: what is staged, flush now, idle the stick, wake it |
Everything else is pipeos --help. A bad save is recoverable: recovery.