Bootcify Nix

[bupd]

@vg006 I believe you could bootcify your nixos system.

[vg006]

Yup, I'm currently looking into archlinux and understanding the difference from the bootcrew/mono images.

Unlike the arch, the entire state of the system is managed by nix engine. So in case of packages update, there won't be much changes in the Containerfile rather will be more on the nix modules. Which means that the system could attain a new state, that's controlled by nixos, but neither cached nor controlled by bootc.

So we need to find a proper way to develop the container image for the NixOS. Hence I'm researching and will be working on that.

[bupd]

Wouldnt it be much easier to check those nix files into bootc containerfile too, so everytime you update and commit the change you made in nix, builds happen in github actions and then sudo bootc upgrade - gets new image and on next reboot you will get the updated things...

[bupd]

the idea is making the system level pkgs immutable like core pkgs like systemd, kernel, ssh etc. these should be coming from bootc upgrade only user should be unable to upgrade this.

[vg006]

Wouldnt it be much easier to check those nix files into bootc containerfile too, so everytime you update and commit the change you made in nix, builds happen in github actions and then sudo bootc upgrade - gets new image and on next reboot you will get the updated things...

Yeah I agree with your point and I'm planning to achieve that, and I explain as follows that why just putting NixOS base image naively into bootc.

the idea is making the system level pkgs immutable like core pkgs like systemd, kernel, ssh etc. these should be coming from bootc upgrade only user should be unable to upgrade this.

So the thing is, NixOS is non-FHS compliant, meaning it doesn't follow the traditional GNU/linux File System Hierarchy and has a special path at the root known as /nix/store path, which is owned by itself and it is read-only. So as per the bootc's doc on read-only and writable paths, this /nix/store path doesn't fall under the read-only paths, hence this could be over-written by NixOS, if we naively package it using bootc. So this will disrupt the bootc's idealogy, as the system could attain a new system just by updating the Nix configs and did nixos-rebuild, without the knowledge or use of bootc.

So we must scope this thing to use Nix either as,

1. Package manager, with another distro say Arch or Alpine, which means only the system packages are just built, cached and served in the image.
2. Entire OS, with the actual NixOS itself, which configures the system from users, processes, networking, FS, etc.

[vg006]

Since both the projects Bootc and NixOS aims to do the same thing (Immutable, Reproducible System Management, from the code), but in different ways, it will be hard it put one into another.

Hence I have this idea, that makes the best use of both worlds, with the Nix as a configuration and Bootc as actual deployment and distribution, let me explain.

Since the entire system is configured in Nix, we could basically evaluate the Nix expressions which produces an intermediary configuration either as JSON or Nix derivation, which is the primitve instruciton set of Nix builds or any other suitable format, and from that we could generate Bootc compatible, safe version of NixOS.

In that way, Nix is just a way to configure the system and environment, but Bootc actually do the job of updating, switching and roll-backing of the states. So this way will highly helpful for existing Nix/NixOS users and reduces the friction, ease the migration job, without losing or refactoring the system into something else manually.

[vg006]

New update on this idea.

Recently I got to know about these tools in the Nix ecosystem, that will make our job much more easier.

1. https://github.com/dauliac/nix-oci
2. https://github.com/nlewo/nix2container

So simply with these, we could create, build, and run containers from the Nix configuration. So it supports different modular systems in Nix like NixOS module, home-manager, flake-parts or even custom dendritic modules.

I'm planning to incorporate this into my new Nix config migration, so let me test and update soon.