Zainium Dynamics
News
November 6, 2026

A base that root can not touch: how Zainium OS works, from zero

Why Zainium OS has no /usr, why we patched OverlayFS, and what immutable really means here, explained from the beginning.

Most Linux systems trust root completely. If a program becomes root, it can replace any file on the system, and a bad update can leave a machine that does not start. Zainium OS began with a simple question: what if the core of the system could not be changed while it runs, by anyone?

This post explains how we got there, in plain words. The technical version is on How the system protects itself.

Start with who owns what

On a normal system, /usr/bin holds programs from the system and from everything you installed. Nobody can tell you what is "the OS" and what is not.

We removed that shared space. There is no /usr, /bin or /lib at the root of Zainium OS, and they are not symlinks either. The system lives in /overlayer, in three layers: the base, your software, and the boot files. Each one has a single owner, and we wrote the idea down as an open standard, the Dualayer Hierarchy Standard.

Then make the base read-only

Other immutable systems do this well too, with images or snapshots, and you reboot to get an update. We wanted installing an app to feel normal, with no reboot.

OverlayFS can join the base and your software into one view, but two things stood in the way. Root can remount a read-only overlay as writable, and the kernel does not expect the upper layer to change while it is in use.

So we wrote a small kernel patch that adds a sealed mount option. A sealed overlay can never be remounted writable, not even by root, and it shows new files as soon as zex installs them.

What testing taught us

The first version looked fine until we booted the live ISO and installed a package. Suddenly ls and bash were gone, with Stale file handle. The kernel had kept the old directory in memory while programs from it were running, and it did not accept that the directory had changed. Later we found that a package upgrade could keep showing the old file, and that a file put in the upper layer could hide a program of the base. We tested that last one on purpose, with a harmless script over the arch command, and it worked. That is not what a sealed system should allow.

Each of these is now fixed. In the folders that hold programs and libraries, the base always wins: nothing in the upper layer can replace or hide a file of the base, and the boot program also clears anything that tries to. We ran the arch test again on the new kernel, with a plain file and with a whiteout, and the base won both times. Installed systems get the fix with elevate zex kernel --u, and the 2026.11.06 ISO includes it.

Sealed on disk too

The view is only half of it. Every base file is sealed with fs-verity, so the kernel refuses to change its content and checks it when it is read. Upgrades happen at boot, before anything uses the base, with a journal that undoes a failed upgrade.

What we do not promise

A system that gives you root can not be fully safe from root. Your settings in etc have to stay writable, and root can change them. So the promise is not that root is powerless. It is that the base stays clean, and that you can always boot it with zainium.overlay=off.

Zainium OS is young and we want it tested. Download it, try to break it, and tell us what you find.