LevitateOS

Documentation

Atomic Updates (A/B)

LevitateOS variants default to an A/B immutable system layout: build the next system in slot B, trial-boot it, then commit. Roll back by booting the previous slot.

Section

What “A/B” Means

A/B systems keep two system slots on disk (A and B). Only one is active at a time. Updates write to the inactive slot and switch boot to it on reboot.

  • Slot A: current system
  • Slot B: next system (built before activation)
  • Persistent state: mounted at /var (includes /var/home)

Section

Update Lifecycle (Default)

  1. Compose slot B (recipes install into the inactive slot, not live /)
  2. Validate slot B offline (sanity checks, expected files, services)
  3. Reboot and trial-boot slot B once
  4. Commit slot B if healthy, otherwise roll back to slot A

See also the stage model in stages.md (Stage 07 Slot B Trial Boot).

Section

Mutable Mode (Optional)

Mutable mode exists for daredevils on public-facing desktop variants (LevitateOS/AcornOS). It allows in-place system mutation, at the cost of drift and a much larger blast radius for recipe changes.

WARNING

Mutable mode is explicitly unsafe when combined with LLM-assisted recipe authoring. Expect breakage. Prefer A/B unless you are debugging or experimenting.

Section

Appliance Variants

Appliance variants are immutable-only. They ship primarily as installed-disk images and are designed to run unattended.

  • RalphOS: agents-only automation host (disk images first)

If you’re looking for a daily-driver desktop experience, start with Getting Started.