{{Header}}
{{title|title=
Dev/immutable
}}
{{#seo:
|description=Explains how different Linux distributions use the term "immutable" and why the definition varies, including distinctions between read-only systems, image based models, and related concepts.
}}
{{boot_firmware}}
{{intro|
There is no single agreed upon definition of the word immutable in the Linux ecosystem. Different distributions use this term in different ways, and it is often combined with or confused with other concepts such as image based systems or stateless designs. This page clarifies how the term is used and how these related ideas differ. This is a general wiki page on the topic of immutability. [[Unspecific|Unspecific to {{project_name_short}}]]. For {{project_name_short}} specific information on immutability see [[Immutable|{{project_name_short}} Immutable]].
}}
= Introduction =
Do you mean <code>immutable</code> or <code>image based</code>?

{{quotation
|quote=Usually instead of talking about an "immutable" system that allows in place updates, it’d be more useful and accurate to say "image based".
|context=[https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ “Immutable” → reprovisionable, anti-hysteresis]
}}

For anti-hysteresis, see also [[Dev/Stateless]].

{{quotation
|quote=Why not "immutable"/"read-only"?

Because it’s very misleading. These system as a whole is not immutable, or read-only, or stateless – there are writable, persistent data areas. And more importantly, those writable data areas allow persistently storing privileged code. They have to because these OSes need to support:

* the user being root on their own computer
* In place OS updates
|context=[https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ “Immutable” → reprovisionable, anti-hysteresis]
}}

= Definition of Immutable =
== Immutable as defined by other projects ==
{{quotation
|quote=Immutable Linux operating systems are aimed to introduce reliable, more secure approach to Linux. For such systems, the core components like kernel, system libraries or critical system files are read-only and cannot be modified permanently. Any changes made to the core system components are lost when system reboots, but many of immutable systems preserve user information, yet it is not obligatory.
|context=[https://github.com/3mdeb/verified-boot/blob/55df31bf0645767e18c4dac7e19bf62d788e9df8/verified_boot_main.md?plain=1#L867 3mdeb Verified Boot research]
}}

{{quotation
|quote=Differently from RHEL images, RHEL for Edge is an immutable operating system, that is, it contains a read-only root directory with the following characteristics:
|context=[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/pdf/composing_installing_and_managing_rhel_for_edge_images/Red_Hat_Enterprise_Linux-10-Composing_installing_and_managing_RHEL_for_Edge_images-en-US.pdf RHEL for Edge documentation]
}}

{{quotation
|quote=Ubuntu Core is immutable and strictly confined. There is a clean separation between the kernel, OS image and applications, each updated independently and protected against corruption.
|context=[https://ubuntu.com/core Ubuntu Core]
}}

{{quotation
|quote=MicroOS is a distribution aimed at providing an immutable base OS for containerized applications. It is based on Tumbleweed package versions, but uses a btrfs snapshot-based system so that updates only apply on reboot. This avoids any chance of an update breaking a running system, and allows for easy automated rollback. References to "MicroOS" by itself typically point to its use as a server or container-host OS, with no graphical environment.
|context=[https://en.opensuse.org/openSUSE%3AFAQ openSUSE:FAQ]
}}

{{quotation
|quote=Bootc systems follow the concept of an immutable operating system. Apart from the following two exceptions, /etc and /var, all directories are mounted read-only once deployed on a physical or virtual machine. However, during a container build the entire file-system is writable.
|context=[https://docs.fedoraproject.org/en-US/bootc/getting-started/ Fedora Bootc documentation]
}}

{{quotation
|quote=Silverblue is immutable and it uses the 'image mode' update model managed by rpm-ostree.
|context=[https://docs.fedoraproject.org/en-US/dei/brand-framework/resource-pack/ Fedora Silverblue documentation]
}}

{{quotation
|quote=Immutable - a file or directory is immutable if it cannot be modified or deleted by the user directly.
|context=[https://abroot.vanillaos.org/ VanillaOS ABRoot]
}}

{{quotation
|quote=An immutable file system is a file system that cannot be changed once it has been installed. It is accessed read-only.
|context=[https://documentation.suse.com/sle-micro/6.0/html/Micro-sudo-configure-superuser-privileges/index.html SUSE Micro documentation]
}}

{{quotation
|quote=Main features of the openSUSE MicroOS is:
* Read-only root filesystem to avoid accidental modifications of the OS
* The Transactional Updates technology leverages btrfs snapshots to apply package updates without interfering with the running system
|context=[https://en.opensuse.org/Portal:MicroOS openSUSE MicroOS Portal]
}}

{{quotation
|quote=Read-only: The primary characteristic of an immutable OS is that the running system cannot be directly modified by users or applications.
|context=[https://ubuntu.com/blog/ubuntu-core-an-immutable-linux-desktop Ubuntu Core as an immutable Linux Desktop base]
}}

{{quotation
|quote=What is an immutable operating system?
Before we can discuss what differentiates Ubuntu Core from other immutable operating systems, we must first define the properties that make an OS immutable:

Read-only: The primary characteristic of an immutable OS is that the running system cannot be directly modified by users or applications.
Atomic updates: Updates are applied atomically; meaning they’re successfully applied all at once or not at all.
Predictable: Because the core operating system doesn’t change, its behaviour is predictable across devices.
Isolated Applications: Applications are isolated from the core operating system and from each other, usually through containerisation. This ensures that changes made by an application don’t affect the core system or other applications.
|context=[https://ubuntu.com/blog/ubuntu-core-an-immutable-linux-desktop Ubuntu Core as an immutable Linux Desktop base]
}}

{{quotation
|quote=RHEL for Edge is an immutable operating system that contains a read-only root directory, and has following characteristics:
|context=[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/pdf/composing_installing_and_managing_rhel_for_edge_images/Red_Hat_Enterprise_Linux-8-Composing_installing_and_managing_RHEL_for_Edge_images-en-US.pdf RHEL for Edge documentation (RHEL 8)]
}}

{{quotation
|quote=By making the system partition read-only, Flatcar Container Linux eliminates a whole class of high-impact security vulnerabilities.
|context=[https://www.flatcar.org/ Flatcar Container Linux]
}}

== Other uses of the Word Immutable ==
VirtualBox has a setting called <code>Immutable</code>. It is documented on the [[read-only]] wiki page.

== Word Reference ==
* https://www.wordreference.com/definition/immutable - allowing change
* https://www.wordreference.com/definition/mutable - unchangeable

== What Immutable Does Not Mean ==

{| class="wikitable"
! Misconception
! Clarification

|-
| The OS can never change.
| You are not completely blocked from installing packages. For instance, Fedora's rpm-ostree allows installing packages. <ref>
{{quotation
|quote=Add a layered package with the <code>rpm-ostree install</code> command
|context=https://docs.fedoraproject.org/en-US/iot/add-layered/
}}
</ref>

|-
| Root is permanently disabled.
| Many immutable Linux distributions still permit root access.

|-
| Updates are impossible.
| Most immutable distributions do allow system updates, they just manage them differently.

|-
| Ephemeral (temporary, RAM-only) changes are forbidden.
| In Vanilla OS (December 2025), running <code>host-shell pkexec</code> opens a <code>root@vanilla</code> shell (if authentication succeded). Checking <code>ls -la /boot</code> shows that there is a real kernel image file (<code>vmlinuz</code>), indicating that this is the host operating system. When deleting an important file, the system will fail to boot. See footnote to see which command exactly. <ref>
Danger! The following commands will make your system unbootable!

* <code>host-shell pkexec</code>
* Dangerous! <code>rm /etc/passwd</code>
* <code>reboot</code>
</ref>
|-

| Confusion of host root shell versus container root shell.
| In Vanilla OS (December 2025), it was possible to use <code>su</code> to become <code>root</code>, then create a test file (e.g., <code>touch /etc/testfile</code>). Listing it with <code>ls -la /etc/testfile</code>. But what's happening here is that this happens inside a container, not on the host operating system. When running <code>host-shell</code>, the output will be "can't run host-shell as root". The same happens when running <code>reboot</code>.
|-

|}

== Conclusion ==
Each distribution defines "immutable" differently. Some refer only to a read-only system partition. Others refer to an atomic A/B update model. Because of this, comparing immutability across systems requires examining the actual runtime mutability.

Some might mean "image-based + atomic updates + easy rollback" or perhaps [[Dev/Stateless|anti-hysteresis / stateless]] when they say "immutable".

= Immutability Security =
TODO: expand

On the [[Grub-live#Security_Considerations|grub-live wiki page, in chapter Security Considerations]] the case is being made that ISO images are the closest to being fully read-only / immutable. But, [[Perfect_Security|nothing is perfectly secure]].

{{quotation
|quote=It's hard to modify an ISO read/write. There is no public software available to really mount an ISO read/write. But it's possible in theory. The ISO should be considered read-write for attackers but read-only for the public. There is the Open Source <code>growisofs</code> tool. Also, other attacks are conceivable. Since [https://wiki.debian.org/RepackBootableISO Repacking an ISO] is documented in the Debian wiki, this can be used for both legitimate and malicious purposes and is much easier than mounting an ISO read/write.
|context=[[Verified_Boot#ISO_Considerations|Verified Boot wiki page, chapter ISO Considerations]]
}}

Maybe it is a valid consideration if there an ephemeral (temporary, in RAM) read-write overlay such as overlayfs that privileged users (such as root) can write to or is the image fully read-only without ephemeral overlay?

Immutability, a read-only filesystem may not be as secure as [[Verified_Boot#Write_Protection|Write Protection]].

= Updating Immutable Operating Systems =

There's always the possibility for updates. But different implementation details.

= Resources =
* https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/

= Footnotes=
<references/>
{{Footer}}
[[Category:Design]]
[[Category:Development]]