Immutable Linux, explained

An immutable Linux distribution is one where the operating system’s own files are read-only during normal operation. You cannot edit a binary in /usr, and neither can anything else: not a package manager, not an installer script, not a process that talked its way to root.

The name is slightly wrong. These systems do change; they just change all at once, deliberately, at a boundary you control, rather than continuously and in place. “Atomic” describes them better than “immutable”.

What is actually read-only

A conventional Linux install treats the whole filesystem as mutable. apt install writes into /usr, a post-install script edits /etc, and over time the system drifts into a state that exists nowhere else. Two machines that received the same packages in a different order are not the same machine.

An immutable system splits this apart:

• /usr, the OS itself, is mounted read-only. It is identical on every machine running that version, bit for bit.
• /etc is writable, because configuration is legitimately per-machine, usually with the shipped defaults tracked separately so your changes can be distinguished from ours.
• /var and /home are writable. Your data is yours.

The practical consequence is that the OS is versioned rather than accumulated. “Which version are you running” has an exact answer, and reproducing a bug does not require reconstructing years of drift.

A/B atomic updates

If the running system is read-only, updating it in place is not possible. That constraint turns out to be a feature.

An A/B system keeps two copies of the OS. One is active; the other is a staging slot. An update writes a complete new system image into the inactive slot while you carry on working. Nothing about the running system changes. When it is written and verified, the bootloader is pointed at the new slot, and the switch happens at the next reboot.

The update therefore has exactly two outcomes: it happened, or it did not. There is no state where half the packages are new. If the machine loses power mid-download, the active slot is untouched and you reboot into the system you already had.

Rollback is the same mechanism run backwards. The previous slot is still there. It was not deleted, it was superseded. Reverting is a bootloader change and a reboot, not a restore from backup. On a conventional system, recovering from a bad update means reinstalling packages and hoping the post-install scripts are idempotent. Here it means booting the other slot.

Implemented on a copy-on-write filesystem, the “copy” is much cheaper than it sounds: the slots share unchanged data rather than storing two complete images.

BTRFS snapshots

A/B slots cover the OS. Snapshots cover everything else.

BTRFS is copy-on-write, so a snapshot does not duplicate data; it records the current state of a subvolume and lets subsequent writes go elsewhere. Taking one is near-instant and initially free in space; cost accrues only as the two states diverge.

That makes snapshots cheap enough to take routinely: before an update, before a risky operation, on a schedule. Restoring is a subvolume swap rather than a file-by-file copy.

One thing snapshots are not: a backup. A snapshot lives on the same filesystem on the same disk. It protects against a bad change; it does not protect against a dead drive. Keep real backups.

Verified boot

Read-only is a property of the running system. It says nothing about what was loaded to get there, and an attacker who can modify the disk while the system is off does not care that /usr will be mounted read-only later.

Verified boot closes that gap by making each stage check the next before handing over: firmware verifies the bootloader’s signature, the bootloader verifies the kernel, the kernel verifies the root filesystem’s integrity. A modified image fails verification and does not boot.

Combined with immutability, this produces a specific and useful claim: the system running now is the system we shipped, and that is checkable rather than assumed.

Why this suits agentic workloads

Everything above predates agentic AI. Immutable systems were built for fleets, for kiosks, for anything where drift is expensive. The properties turn out to matter unusually much for agents.

Agents change things. An agent installing a dependency, editing a config, or running a script it wrote is doing what you asked. It is also doing exactly what an unreviewed change is. On an immutable system the OS is not a valid target: the write fails because the mount is read-only, not because a policy caught it.

Exploration needs a bounded downside. The useful version of an agent tries things. That is only reasonable when a bad attempt is cheap to undo. A snapshot converts “the agent broke something” from an investigation into a reboot, which changes what you are willing to let it attempt.

Recovery must not depend on understanding the failure. Conventional recovery requires working out what changed. With an agent, the change may be a long sequence performed by a process whose reasoning you cannot fully reconstruct. Slot-swap recovery does not care what happened; it restores a known state without needing a diagnosis.

Attribution needs a baseline. If the OS is identical on every machine running a version, then anything different is either your configuration or something worth looking at. On a drifted system, everything is different and the signal is gone.

The costs

Immutable systems are not free, and the trade-offs are real.

Installing software is different. You cannot apt install into /usr. Applications come as Flatpaks or containers, and development tools live in a toolbox container rather than on the host. This is a genuine adjustment, and it is the most common reason people bounce off these systems. It is also the mechanism that makes per-app sandboxing possible.

Updates require a reboot. The switch happens at boot. Some systems can stage the new slot and let you defer, but the reboot is not optional.

Some things genuinely do not fit. Out-of-tree kernel modules and drivers that expect to write into the system are awkward, and layering them is possible but adds a step to every update.

Disk usage is higher. Two slots plus snapshots costs space, though copy-on-write makes it far less than doubling.

Whether these are worth paying depends on the workload. For a machine hosting processes that autonomously modify things, we think they clearly are: the properties align almost exactly with what an agentic system needs. For a workstation where you are the only actor, it is a more balanced call.

Where MeghaOS sits

The MeghaOS operating system edition is image-based: the installer writes a complete system rather than assembling one package by package. Every machine on a given version is the same machine, which is where the reproducibility and no-drift properties above come from.

At the workspace level, the agent-exploration case is already covered: every turn is checkpointed, and undo rewinds files and conversation together. Extending that model down into the system, along with the boot and root-filesystem guarantees described here, is what the Linux editions are being built toward. The security page tracks where each piece stands.

---

Related: The full immutable stack · Architecture, layer by layer · Why an agentic AI needs to be an operating system