How does znx work? — Understanding how znx manages a device

What is znx?

https://github.com/Nitrux/znx/wiki

znx is a tool that lets you use multiple operating systems and keep them updated without having to repartition the drives. It’s all about simplicity and reliability.

How does znx store data?

We store data directly on the device without intermediate files. In Nitrux, at boot time, it creates an overlay mount on `/etc.` and `/home.` znx further extends the concept of frugal installations (we call them “deployments,” not installations) by also serving the updates (which is a very critical state).

It does not just manage the deployment, but also the whole lifetime of an image; this is, updating it safely (and keeping a backup of the last working version) and, possibly, discarding it. znx is designed to work only on UEFI.

The following diagram illustrates how znx stores data in a device.

How does znx manage OSes?

We are primarily using znx at Nitrux, and it’s often the case that users do not understand why they would use znx in the first place. Znx, as we have reiterated in previous articles, is not an installer since the way that it works is not by extracting the contents of a SquashFS file but instead booting the ISO file itself, and because it also performs other tasks.

Using the diagram pictured above as an example, what znx does is to create two partitions, one for the ESP (ZNX_BOOT) and one for the user data (ZNX_DATA). And, within ZNX_DATA, each operating system that is deployed with znx is contained within an individual folder.

One of the points of using znx is that instead of each operating system being extracted to an individual partition that each is mounted using OverlayFS.

Yes, znx needs to manage the entire device; however, each deployed system is not limited by the size of the partition that would otherwise be in, but rather it can make use of the entire free space of the device. Also, with znx, it is possible to have multiple versions of a single operating system side-by-side, e.g., ver_1, ver_2, and ver_3 neglecting once again the need for more partitions.

For example, in the image, deploying OS_1 does not mean that it will take up the entire device, since the ISO image of OS_1 is only, e.g., 2GB meaning for the user that there’s 237GB of free space.

Moreover, if the user deploys a second operating system, for example, OS_2, the same logic will apply; let’s say that OS_2 ISO file is 1GB in size, which means that for the user, there’s still 236GB of free space.

So on and so forth.

In this instance, there’s the availability of a multiboot system, but there’s no need to have OS_1 in a partition separate from OS_2.

Since each operating system is a file that znx boots, no potential problems are arising from having each operating system adding their bootloader entries to the ESP, the only bootloader file in the ESP is that of znx.

Additionally, the user data of each operating system is contained within the same folder using OverlayFS once again, avoiding potential problems of a shared home folder and the need for multiple partitions.

This is not to mention that there’s no need to manipulate partitions to accommodate for further deployment of operating systems as one would have to do without using znx.

Use cases of znx

For the following, let’s see how other similar systems work, for example, with Android. When you purchase and Android device, its internal storage will come with a layout that is similar to that of znx.

The difference would be that to use a different ROM, you have to flash the device, and with znx, you could have two ROMs with multiple versions side-by-side.

Another example is with updates. When an OEM updates a device, no reinstallation or no partitioning is happening either. It’s seamless.

With znx updates are also seamless, znx will check for a zsync file, if it matches, it does the updates, and it does them in a transactional way.

Equally to Android, the user is capable of doing a “factory reset.” Znx has the capability of resetting a device (in other words, cleaning the overlay), which once again neglects any need for reinstalling the operating system.

Downgrading is also a feature that znx implements. To downgrade a Linux distribution that uses a conventional installer, you would have to reinstall the operating system, to lower the version of Android you have flash an older ROM. However, none of this is necessary with znx; znx allows the user to revert to the previous version or, in its development branch, select it from the znx boot menu.

Znx doesn’t negate the use of package managers; a user could use a package manager to manage the OS, with znx providing a “safety net.”

Common misconceptions about znx

So, to recap, znx is not:

1. An installer. An installer, like a package manager, extracts the content of an archive, znx does not do this.
2. A container technology. An OS that is deployed with znx does not run on top of a host.
3. A tool to (explicitly) flash storage devices (like USBs). znx does not write ISO files raw to a storage device like dd does; it copies them and manages the device.
4. A hypervisor. An OS that is deployed using znx is not being virtualized in any way.