Considering new installation approaches

Currently the size of the Gnome ISO is halting the progress of nixos-unstable for more than a week now, and there are currently different approaches to mitigate the problem short to midterm.

This ranges from reducing the size of the ISO (short term) to temporarily increase the allowed size of store pathes (mid term).

In my opinion, the only viable long term solution is to remove the Gnome ISO all together, among all the installers it has the worst UX (yes, even worse than the minimal, as the minimal at least shows a greeting).

My suggestion to new users is always the Plasma ISO, as the most needed things for the installation are right there as desktop shortcuts. GParted, a Terminal and a link to the docs…

Usually the only reason for using Gnome at all, is because the generator uses a template that enables Gnome as default DE instead of Plasma.

On the other hand side, there have been experiments with Calamares to create a fully fledged installation wizard. I still consider this approach a viable solution, but due to the fact that it is an ongoing project that started before I began to use Nix, it will probably never really finished.

Therefore we discussed a new idea in the Discord yesterday, which I want to present and further discuss here, before it might get solidified into a RFC.

The main idea is to not have different templates for the generator based on the installer used, but instead make the generator aware of “flavors” which can be chosen using a command line argument.

Such that one can use nixos-generate-config --root /mnt --flavor plasma to generate a plasma based configuration, or --flavor gnome3 for Gnome. Another built-in flavor could be minimal or non-gui or something like that.

In general the discussion in the Discord quickly evolved in a lot of suggestions for different flags that controll different aspects. This got quite complex quickly such that the next idea was born.

A generator that asks questions interactively for the various aspects.

  1. Desktop flavor: plasma, gnome, xfce, none and whatnot.
  2. Network: pure declarative network management, mixed mode or network manager
    1. hostname
    2. depending on the choice ask more questions to make sure there will be network after boot, including offering of the unfree wireless drivers to increase probability that network will work after boot
  3. Initial user creation
    1. Ask for an inital password and set initialHashedPassword.
    2. User groups
    3. user shell (and enable that shell through programs.$shell.enable as well)

Other suggestions that have been made, included interactive setting up of services, though for a CLI generator that task has been considered as too complex, as one had to skip all the not needed services manually, or there had to be an overwhelming list of services which one had to choose from. After some discussion we considered both variants as not necessary for the first iteration or as a valuable enhemcement for a GUI based generator.

But it has also been asked, whether or not we can get a --flake option which would not only create the config but a flake skelleton as well.

Ultimately this approach would allow us to have just a single ISO with a minimal GUI environment. Someone in the chat suggested LXQt as beeing simple, small and functional. As an alternative using a WM has been discussed that gets configured in a way that everything necessary is accessible from the “desktop”, including NetworkManager and a reboot button.


There was also a proposal by Eelco to move ISOs out of the jobsets a long time ago:

I have to disagree, the main benefit of a graphical environment (be it Plasma or GNOME Shell) is that it is inherently more user friendly thanks to familiarity. It is also much more convenient – I have, in the past, used links with the minimal image to search web for documentation but that is a terrible experience compared to being able to have a terminal window open side by side with a modern web browser and being able to select text with a mouse and copy it between the windows. (Some people can do all of these things on tty but I certainly cannot.)

The primary reason why we switched to GNOME as a default was that Plasma did not support Wayland at the time, which reportedly made HiDPI displays on some laptops unusable. GNOME also had significantly more active maintainer team, mostly thanks to @worldofpeace. Now that Plasma has Wayland support, we can re-evaluate it.

I think config generators are good idea but completely orthogonal to what images we will offer.


I’m not proposing to remove all graphical installers. Only Gnome, as it does not only require familiarity with Gnome itself, but also with the NixOS installation procedure, as you get booted into a blank screen without any desktop items or explanation…

1 Like

The only difference between GNOME Shell and Plasma is that the latter has the shortcut pointing to manual, gparted and terminal on the desktop. I agree that this is useful so I have opened to rectify that.

I suspect the reason they were omitted was because installation is not the ISO’s only purpose – it also serves as a showcase how the installed system might look. WORLDofPEACE likely focused on this aspect, aiming to achieve an experience as close to vanilla GNOME as possible.

To clarify, even though I am a maintainer of GNOME on NixOS, I do not really care whether we will have an official GNOME ISO. We should keep it if it is useful. And that is determined, more than by any technical factors, by the soft stuff. Hence, the marketing team is the proper entity to decide.


I like the idea of keeping the official “installer” small and additionally provide more usable live-ISOs which would be able to showcase NixOS features but could also be used for installation (though not being their primary focus). The latter though should never block the channels.

Currently it seems as if we have the minimal ISO, which can be used for installing only, but not really, as it lacks network manager and requires knowledge of the wpa_supplicant CLI for hosts that do only have WiFi available.

Additionally we have 2 “showcases” which are mostly used for installation only but probably would require much less software for that job…

On the other hand side, I do not really see how a static ISO would be able to showcase nix. You can not rebuild that systems configuration, and as soon as you try to install anything that is a bit bigger, you’ll run out of RAM quickly.

Our main target should be to provide an ISO that can be used for installation, suits even small bandwidths, and has a GUI that does not hide anything while not being overwhelming.

Calamares (or another installation wizard) being the ultimate goal for the installation medium.

Providing Live-ISO, which perhaps could be built in a way that you can put them on a 64GB thumbdrive and have a “writable” store, persisting across reboots, should be a long term goal for the show cases. Perhaps there should be teams working on either.

Please understand that I do not try to argue against Gnome in general, just about what I have seen from the Gnome-ISO so far and why I consider it unsuitable in its current form for installation.

1 Like

We definitely should keep a GNOME ISO because people want to know their hardware works on the DE they want to use before committing to it and GNOME is a popular DE. I don’t think it should block the unstable channel.

Thank you for bringing up and helping to fix the GNOME UX, I agree that it’s terrible right now.


Specifically for “flavor”, there is the concept of templates that would could easily be re-used here. That may not be available as a default until 3.0, but seems to be the cleanest way

1 Like

It won’t, “flake templates” are not composable and not parametrisable.

Making them suitable for the tasks and choices outlined above will take far to long I think.

For now the problem with the ISO not being built is solved.

I like the @edolstra’s idea of moving iso generation to a separate build. Regardless of whether we want to improve the ISOs or remove one of the flavors, it makes sense to keep it separate from nixos-* channels.

As for the flavors, for some services we have recommendation options. Like for nginx recommended security and proxy options: NixOS Search - Loading.... Just a boolean that when set will set different options that ‘should’ be considered the default.

Maybe it makes sense to have some more of these recommended options in NixOS. In addition, one of these recommended options could be recommendations for Gnome. I think the same can be done for pipewire, Wayland (finnicky environment variables for Qt, GTK, etc). When gnome recommendations are enabled, the pipewire and Wayland recommendations are likely to be enabled too.


The issue with any image-based outputs is that we’re not benefiting from de-duplication. We’re having the same issue with AMIs, Docker images, … Each build duplicates all of the store path and increases the size of the cache considerably.

Instead of blocking the channel advance on the ISO generation, we should switch to only building the system closure of that ISO. If that builds, the likelihood of the ISO not generating is pretty low. Do this for all image-based outputs.

Then separately, introduce a cronjob that builds and publishes the ISO, AMIs, … And push those to the respective targets instead of the NixOS cache.


I created as a way to avoid ISO building/tests on unstable channels. It is not the solution @edolstra suggested in, but it seemed a step in that direction.

It’s fine to close it if it isn’t a step in the right direction. I couldn’t really figure out how to do ISO generation as a separate jobset/cronjob in Hydra.

1 Like

I agree that the current Gnome experience is pretty bad, but I think the solution rather than removing it entirely is to add calamares to guide the user through an installation.

I’ve been recently trying to fix calamares on NixOS to hopefully fix this. I made a proof on concept ISO here (Also above 2Gb though. Not sure if it’d even be possible to optimize it below). Some form of templates or flavors in nixos-generate-config could definitely help though, and would be able to be integrated into the calamares modules I’m working on.

I think an ideal solution would be to boot directly to a DE, whether that be Gnome or Plasma, and launch calamares, where the user could pick which desktop environment to install, by default whichever shipped with the ISO. I haven’t had a chance to work on that recently, since busy with studies, but I also agree that currently, the Gnome UX on NixOS is not ideal. Another project I’m working on is a dconf-editor esq app similar to nix-gui but instead using a tool I made, nix-editor to modify the AST directly, hopefully leading to more stability. Hopefully with this, users fresh off a calamares install can be guided and taught nix syntax.

But for now, I think the best solution to this would be to add calamares to both the Gnome and Plasma ISO, that way new users can at least install NixOS with ease, even if having to learn more afterward is harder.


I may be completely off-track here, but as I recall from looking (a while ago), the gnome (and other) ISO’s aren’t just made to be installers, they’re also booted and run in a VM as tests of the DE as a whole.

That’s part of why the failure is blocking things; in terms of dependencies, the current test construction basically sees this failure the same as gnome not starting.

1 Like

DE tests like Gnome startup do not use ISOs, I believe.

1 Like

Awesome! Calamares looks promising to give users a installation experience that they are used to. A future addition could be to show the user the resulting configuration.nix, but having it be a simple wizard that guides through formatting already helps people get started.

Do you think it’s a good idea to create a (draft) PR of your branch? That way we can comment there and it can get some more exposure.

This also looks very promising. In the past I’ve been working on a cli to give the user the experience of:

nix install --local package
nix install --user package
nix install --system package

that just edits a JSON file with a new package, which gets imported by configuration.nix, home.nix or shell.nix. With nix-editor this could change the Nix file itself, very cool!

While we supply both variants of the ISO, I agree. Though I don’t know why we have two variants in the first place.


Created a draft pr here:


Can you also provide some initial build instructions to test it? Or is there actually nothing that pops up yet?

To build an ISO, after cloning, run

cd nixpkgs
nix-build nixos -A -I nixos-config=nixos/modules/installer/cd-dvd/installation-cd-graphical-calamares-gnome.nix

This will build an ISO in the result directory


Very cool! I tried it in QEmu:

qemu-img create nixos.qcow2 2G
qemu-system-x86_64 -cpu host -m 2048M -accel kvm -vga virtio -cdrom nixos-22.05pre-git-x86_64-linux.iso -drive file=nixos.qcow2,if=virtio

I took take a few screenshots to give some impression how the experience is:

I’m quite impressed how it looks and I think it’ll help people quite a bit initially. Having a Erase disk, asks ‘this just works’, partitioning option would help quite a bit trying NixOS.

People do need to get to know configuration.nix after the installation. Still though I would’ve used this if it was available at the NixOS install-party I attended with colleagues. It would’ve avoided some finicky problems with partitioning and setting the right options in configuration.nix the first go.

The installation did fail for me this time. I liked that it asked me to upload the logs to It just didn’t give me enough information to go on yet.
That said, I did run it in a VM with only 2GB disk space, which might’ve not been enough for the configuration that the installer defaults to.


I tested the configuration you ran in debug mode and got an error with nixos-install due to space requirements: However, I think your error occurred before mine, but I believe it was caused by lack of space as well. I’ll look into adding better error messages for the nixos modules.