Luis M. Lavaire edited this page Nov 23, 2018 · 8 revisions

A simpler approach.

With 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.

What is 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 znx's operations.

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:

Boot partition:

  • /boot/grub/grub.cfg
  • /efi/boot/bootx64.efi

Data partition:

  • /boot_images
  • /data
  • /data/home
  • /data/etc

Deploying images.

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.

Reverting updates.

znx creates a backup of the image during an update. When an update is reverted, the old file replaces the new one.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.