Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
A simpler approach.
znx we try to simplify the process of deploying and managing the updates of multiple or single operating systems deployments on a machine.
znx introduces a new approach for distributing and using Linux-based operating systems. The content of the images that you deploy are never extracted to the storage device (compare this with AppImages). Instead, they are loaded pristine at boot. This makes the deployment process very easy and fast. Updates are also very straightforward.
znx will look for an URL embedded in the image. It then invokes
zsync which performs a differential update. If the update process fails, it can be resumed later or discarded. The system will never be broken after or during an update.
znx comprised of?
znx is basically three files:
./znx: This is a UNIX shell script. It helps to manage the deployments, updates and removal of the images.
./boot/grub/grub.cfg: This is a GRUB2 script. It detects the deployed systems at boot.
/efi/boot/grubx64.efi: The UEFI specification defines that file as the default boot manager.
Those three files are all that is needed to perform all of
What happens under the hood?
Initializing the device.
The first thing you have to do in order to use
znx is to initialize the device.
znx will wipe the device and create a new GPT partition table on it, with two partitions. One of those partitions stores the bootloader data, while the other stores user data (including the images). Those partitions are then formatted with the
FAT32 and the
BTRFS filesystems respectively. After that,
znx creates some directories on both partitions, as well as copying some files to the boot partition. Once those things are done, the device is considered initialized. What is seen on an initialized device is the following:
Images are stored on the
/boot_images directory of the data partition. Inside that directory, a hierarchy of subdirectories that match the name of the image are created. So, when you, for example, deploy
your_distro/rolling, a directory
/boot_images/your_distro/rolling is created in the data partition. Then, the image is stored in that directory.
Booting the device.
After you deploy an image on the initialized device, you can boot it. GRUB2 will show up a menu of the deployed images. GRUB2 provides the
loopback command, which is similar to the
mount command in *nix systems. The boot script (
/boot/grub/grub.cfg) calls the
loopback command to "mount" the selected image. Then, it extracts the kernel, the initramfs and proceeds to boot.
Updating deployed images.
We use the
zsync command to provide differential updates. You can read more about
zsync here. The URL from which
znx retrieves the differential content should be embedded in the image (the distribution developers are in charge of supporting this method). See this issue for more information about how this information is stored in the image. These updates are atomic, also, because if the update fails, the active image is not overwritten. The update can be resumed later. If the download succeeds, then the active image is kept under a different name, which allows rollbacks.
znx creates a backup of the image during an update. When an update is reverted, the old file replaces the new one.