Starting work on NixOS Template

Hello there !

I’m just trying to gather some advice and opinions before trying to create a NixOS qubes template.

Having an available NixOS template would be incredibly beneficial for software developers using the platform and I’m looking to contribute. Either by starting the project from scratch or working with others who already started going down that path.

Basically the goal here would be to “automate” and standardize framework specific developer environments.

I’m looking for any advice, opinions about this project. Anybody created a template before ? How long / complex was the endeavor ? Things I should be aware of ? Possible blockers ?

I already looked at this post: Building a TemplateVM for a new OS wondering if there might be any other resources that would be helpful.

Thank you in advance for your answers !
eject_cosmos

8 Likes

There is probably some useful stuff in older threads like this:

I bet @solene has some good info.

1 Like

install nix and compiling all necessary packages using nix are two different things. I think https://discourse.nixos.org/ is a good place to get help.

1 Like

How far did you get with this? I want to start with NixOS in the near future so it would be great if making a template is possible.

Hi. I’m working on a Guix template which is based on the same underlying technology as NixOS, so I’ll share where I’m at right now. It’s not very far.

Packaging Xen and Linux with QubesOS patches was fairly straightforward, as you might expect. I’ve also packaged qubes-db and started qubes-linux-utils, and again these were easy to package. I have a networking service that sets up the virtual interface correctly based on QubesDB and this was not too complicated, although I’ve had some problems with losing networking state if I disconnect my ethernet cable. Restarting the networking service fixes that. QubesDB has a function for monitoring changes to entries which might help solve that problem but I haven’t looked into it too much. Right now it’s just “run ip addr add/ip route add/etc on service start, equivalent delete commands on service stop, do nothing while the service is ‘running’”.

I’m currently working on booting my HVM Guix install in PVH mode. I’m starting with booting a Fedora-based template with a kernel built by Guix. Which is fine for the most part but memory ballooning isn’t working properly so I have to give the VM a lot of min memory. Otherwise it seems to work fine, the VM boots and I can do things in it. The next thing I need to tackle (aside from the ballooning bug) is starting the correct init in Guix. I assume that Nix will have a similar issue. In Guix, there is a list of bootloader entries pointing to different profiles in the kernel command line which is used during initialization. The problem is that the command line arguments live in dom0 when booting in PVH mode. Maybe some dom0 script could read the bootloader configuration and ask the user, but having dom0 parse VM data seems like a bad idea. So it would probably be better to have a separate init in Guix that asks the user which profile to use separately from the bootloader.

Anyway I’m short on time so that was just what I remember. Some of the pages in my personal note are relevant to my effort to build a Guix template and they might be helpful here as well. You can also see my current progress in my channel.

Good luck!

7 Likes

awesome!

why don’t you just boot on the latest system version? it has a fixed name IIRC

1 Like

I might do that temporarily, but I want the ability to roll back to previous configurations on boot. I tend to do strange things to my computer and sometimes completely break everything. :upside_down_face:

Qubes OS provides a pretty similar feature, not as practical though, but you can revert the qube disk to its last state, the number of stored states can be configured.

See Volume backup and revert | Qubes OS

That’s great! Nix has way more packages then anything else, so is a great way to access all the applications that aren’t in debian, fedora, or one of the other templates on qubes.

Doing the “nix on top of debian” method works, but you have to do the “nixGL” thing to be able to run GL programs, making it hard to explain to people how to use it. Presumably a full nixOS template would not have this problem.

Thank you! I had no idea that it was keeping snapshots, and assumed if i wanted to use snapshots, I’d have to go in and do it manually with lvm

That’s neat. I’ve been interested in trying out guix. I look forward to it.

@eject_cosmos , @skyvine , what’s the state of your projects? Is there a repo to contribute to?

Edit: Sorry Skyler I missed the link.

I don’t know anything about NixOS. Can someone explain what are the advantages of having one compared to any existing?

NixOS configuration is done by using a declarative language. You just have to write a few lines of code to tell you want which packages installed for which users, and what services should be running.

This would be ideal to have a programmatic OS in Qubes OS.

Combined with the built-in salt it makes management easy. Dare I say trivial.

Another feature is that it is not only declarative, but whole config is stored in one file (almost)(unless you decide to separate it on purpose). It makes reproducibility much easier. It would be particularly useful in qubes, for setups which are now described solely in community guides, like audio qube, and other applicable situations.

This also allows version management of your OS and easy rollback if your config edit breaks something (which is one of default features of NixOS).

I made a NixOS 101 video at my previous job for people who would like to understand what it is and how it is different from a traditional OS.

4 Likes

So is there a github repository to test and/or contribute to?
I’m also very interested to integrate nixos into qubes.

There is Skyler’s channel on sourcehut. It is not nix and not on github tho :slight_smile: . Last activity was 2024-07-28.

Should we create our own repo at this point? @eject_cosmos haven’t showed up since april.

A few things:

First, I want to be clear that I’m not trying to hijack this Nix thread into being a Guix thread. I brought it up originally because OP was asking a broad question about what kinds of challenges might arise for adding more comprehensive Nix support. Guix and Nix are very similar so I believe that my experiences are relevant to that question, but I also believe that “this is technically Guix not Nix” is an important caveat. They share the same core engine and design, but the stuff built on top of that is completely different. However, since that time there have been a couple of Guix-specific posts. I’m replying here because that’s where the posts are, but I would be supportive of splitting these posts into a separate Guix-specific thread.

It’s not on github but it is a git repository. I just want to make sure that is clear because I’ve run into some people (including professional developers) who are under the impression that git is a github-specific tool. The mistake is understandable because github is such a dominant hoster and the names are similar, but you can clone the sourcehut repository just as easily as a github repository. I do not believe that hosting on sourcehut should be a significant barrier for anyone to use, modify, share, etc the code.

Just for awareness, development is slower now than it was before in part because I recently returned to full-time work. This not only means I have less time to work on the project but also exposed some deficiencies in my workflow. For example, I recently updated my Guix VM and this included an update to the linux-libre package definition. This means that I can’t fully test any new code until I finish re-building linux-libre with the configuration and patches provided in qubes-linux-kernel. I won’t leave my computer turned on overnight for reasons, and it takes more than a couple hours for my machine to build the kernel, so it’s been challenging to work on the project this past week. I am in the process of improving my workflow so that these delays occur less frequently and less severely.

However, that is not the only factor causing the project to move slowly. I am also working on some more academically-oriented things. This will eventually converge with my work integrating Guix and QubesOS, but both of these domains are relatively new to me so there is a learning curve. I am also extremely dissatisfied with the way I have gone about the work until now. It’s basically just been “write a package definition that uses the pre-existing build system, see if tests pass and some basic functionality works, and assume all is good”. For a couple of smaller repositories I have read large portions of the source code for anything obviously problematic, but I wouldn’t say that I actually understand how these systems work or how they are related to each other. Assuming that things are fine because they look like they work when I try random things on my machine, without actually understanding why they work, makes me feel nauseous.

Addressing this deficiency is one of the ways in which my academic work and project work will eventually converge. I am aware that there have been historical efforts to create software system descriptions (UML diagrams come to mind) and automatically analyze project structure (I remember seeing at least one paper that analyzes coupling between modules by counting cross-module references on the syntactic level). However, I do not know what the state of the art is and I’ve never actually used these tools personally. I am desperately hoping that I don’t have to do anything novel in order to create a process for understanding a code base.

I’m happy to collaborate with anyone working on Guix/QubesOS integration or Nix/QubesOS integration, whether that means collectively contributing to a central repository or working on separate code bases in parallel. In particular, if there is parallel work on Guix and Nix then some amount of cross-project alignment will probably simplify upstream integration, if any changes to the QubesOS code base need to be made.

3 Likes

This is a MONUMENTAL task considering that NixOS is not that stable when using the unstable channel where the really good things are. Currently I use a Kaisen (rc2 template) because of stability and safety. Maybe Nix infect or some other installation will cut it. Don’t give up but don’t feel bad if you fail. Get a good junk yard dog chain and chain yourself to the screen. If it was not my supersecret template I would share it with you.