With znx, you can forget all about using installers and partitioning your storage device. znx allows you to quickly deploy multiple operating systems on one run with a straightforward approach.
In this article, we’ll focus on Linux and EFI systems.
With conventional installers, typically, installing a new distribution means using a default partition layout for the operating system, this means that your entire device is used up by one operating system, utilizing one partition which contains the ESP, the root folder and the home folder plus the swap partition. But if you’re the kind of person that likes to check or use more than one operating system, you would instead use what is known as dual-boot or multi-boot.
In a dual-boot or multi-boot scheme, the partition layout is changed to reflect this necessity. If there were more than one operating system installed on a single storage device, the number of partitions grows accordingly. For example, an installer will offer the user the option to either
A) Erase the storage device or Replace the existing partition to install the new operating system,
B) Install alongside the current operating system or
C) Something else or Manual partitioning.
So, option A is out of the question. Therefore it’s either option B or option C.
Since you want to install a second operating system you need first to shrink the existing root partition, then create the required partition(s) for the new system, best case scenario you only add another partition for the root folder of the second operating system, the installer would handle this.
But what if you used a custom layout already for the current operating system? For example, a familiar custom layout is to use three partitions, one for the ESP, one for the root folder, and one for the home folder. For EFI operating systems, the ESP can be shared, and so can be the swap partition and the home folder though to an extent it’s better not to share it. However, the root partition can’t be shared between different operating systems since doing that will most likely cause conflicts.
In this case, you need to add at least another partition, two if you want to be safe, so you end up with more partitions in your storage device every time that you add another operating system.
Another thing to consider to an extent is the storage space that a new operating system utilizes. A typical desktop operating system consumes about ~4–5 GB after installation, so that’s at least 4–5 GB consumed for every new root folder partition.
All this complexity is unnecessary, and with that in mind, we developed znx.
With znx, every single operating system that it deploys remains as an individual file in the storage device, effectively consuming less space. Utilizing znx means the complexity of using more operating systems decreases.
Znx is to operating systems what AppImage is to application distribution. And just like with AppImage, it is distribution agnostic.
You may ask yourself if znx works by utilizing the ISO files of Linux distributions, wouldn’t that mean the ISO files that it deploys to the storage device would be Live CDs? Yes and no, let me explain.
With znx, there are only two partitions on a storage device, the ESP and the Data partition. The Data partition is where znx saves the ISO files; it, too, will contain the data for every folder that utilizes the OverlayFS. The Data partition occupies the rest of the available space in the storage device.
OverlayFS provides a great way to merge directories or filesystems such that one of the filesystems (called the “lower” one) never gets written to, but all changes are made to the “upper” one. Brought into the Linux kernel mainline with version 3.18, OverlayFS allows you to overlay the contents (both files and directories) of one directory onto another.
They would be Live CDs in the sense that they would be ISO files that utilize a SquashFS file, and that would typically mean that whatever you do is lost after a reboot.
However, as we have proved with Nitrux that does not have to be the case as we utilize OverlayFS, albeit we only enable it on certain parts of our ISO given that in our specific circumstance with Nitrux we do not intend to use a package manager but AppImages as our primary method of software distribution for end-users.
But let’s say that a third-party distribution vendor decides to use znx, would that mean that they would have to relinquish using their package manager too? No, not at all. The only modification required would be that the ISO file is adequately modified to use OverlayFS, and their ISO file could then be deployed using znx. It would be able to have persistent data across reboots, and users would correctly be able to use the package manager still.
Yes, it’s that simple.
In this regard, znx would be of use as a sort of default state or factory reset mode wherein a case of failure for any reason; users can go back to an initial state without having to reinstall the operating system at all.
Both Wubi and UUI use a file that serves as a storage device. That file is mounted at boot time as a union filesystem (either aufs or overlayfs). This permits the aforementioned data persistence.
We store data directly on the device, without intermediate files.
As noted in the article, znx significantly differs from these solutions in what it’s scope is. Taking the previous example, with znx, third-party vendors could also adopt delta updates in their ISO files.
At its heart, znx uses Zsync (hence the z). Zsync will calculate the difference between the old and new files in a remote server and download only the changed parts. By utilizing Zsync, znx can save the bandwidth that would otherwise be used to download a new ISO file.
To make use of this feature, the vendor has to embed the updated information in the ISO, then znx can adequately make use of the Zsync file that would be generated during the creation process to update the ISO image.
This ease of use would also mean that for an OEM, it’s simpler to deploy an operating system to multiple storage devices down the production line, as well as being able to provide their customers of a way to reset their computers and for them to update the included operating system safely.
When it comes to doing the deployments, znx is flexible; for example, the ISO image doesn’t have to be locally on the computer; it can be a remote ISO file. Once again, saving time and only utilizing bandwidth once. Future deployments are also simplified, for instance, let’s say that you have deployed Nitrux and you want to re-deploy it to another storage device, do you have to download the ISO again? No, not at all.
The ISO file is located in the Data partition, which means that you can reuse it since it’s already there.
Another feature of znx is its ability to perform rollbacks. znx allows users to return to the previous version of the ISO image if the new file is causing trouble. All while keeping user data intact.
With znx, there is no need to reinstall an operating system, and in the case of Nitrux, there’s no need for a package manager to update it.
For enterprises, znx means stability. Deploying an operating system is simplified, and so is maintaining it. Delta updates make sure that the operating system is upgraded safely, and the rollback feature allows to, well, roll back to the previous working version.
Utilizing znx to deploy multiple operating systems also helps with GRUB2 management. Every operating system will be added to the GRUB menu of znx, avoiding any problems that come of using multiple root partitions.
We continue to work and improve znx, and as a result, enhancing Nitrux. You can find more about znx in its wiki, znx is Open Source software.