What to show in list of NixOS generations?

I have an open pull request that adds two things to nixos-rebuild: With --generation you can switch to a specific generation instead of a rollback. For ease of use, I also added a command to get an overview of the available generations. Its output is currently based on the boot loader menu and looks like this:

$ nixos-rebuild list-generations
Generation  NixOS version               Kernel  Build-date
290         21.03pre253635.2247d824fe0  5.9.9   Sat 2020-11-28 16:09:53
291         21.03pre253635.2247d824fe0  5.9.9   Sat 2020-11-28 16:20:51
292         21.03pre254279.6f0c00907bb  5.9.11  Sat 2020-11-28 19:07:38

What else do you want to know in an overview of the generations?

  • Could some information on flakes (if available) be useful? Maybe nixos-version --revision output? Truncated?
  • Is the configuration-name of interest? Do you use it in a way that makes sense to show it?
  • What about showing it in a pager? The output might be long - on the other hand this makes it eager

I would like to hear about your ideas / what you would like to see

10 Likes

If built from a flake, the commit of the flake would be nice (or if it was built from dirty)

1 Like

I’d like to see the profile name please (as defined by nixos-rebuild switch --profile-name).

All of that sounds fantastic. Thanks for doing this.

This is fantastic functionality, thank you! I’ve been thinking for a while if it might be useful to create a nixos command similar to how all the nix-* commands are being consolidated into nix. So you could do nixos rebuild ... or nixos options ... or nixos list-generations.

Alternatively, I was thinking we could provide a mechanism to extend nix with custom commands, similar to git. So then an os subcommand could be autoloaded only when nix detects it’s running in NixOS. Providing a similar nix os rebuild etc.

2 Likes

There is an open pull request: tree-wide: rename nixos-rebuild to nixos-config by zimbatm · Pull Request #100578 · NixOS/nixpkgs · GitHub to rename the nixos-rebuild command with a comment at the end if it should just be nixos. So some people are thinking similarly to you. I personally would support this especially with all the UX improvements that have been/are being made to the nix command as well this might be a nice follow up.

Also great to see the generations UX improvement, that was pretty confusing for me when I first started using NixOS, so much appreciated.

1 Like

Thanks! I didn’t know about --profile-name before… Would it be okay for you, to list the system generations by default and with -p/--profile-name you can list the other profile generations? Maybe there should be another list-profiles subcommand, but I guess this is not quite related to this pull request…

1 Like

IMO, yes.

Thank you for this work!

1 Like

Is there any other way to figure this out, apart from specifying the system.configurationRevision
as described here? You could see that with nixos-version --json | jq .configurationRevision. What should the default value be, if that was empty? not available, unavailable or just empty?

That doesn’t work for me. There is no configurationRevision in the output.

Neither can I use nixos-option syste.configurationRevision as my flake does not live at /etc/nixos. So the only option I currently see is to write some file where I drop that information.

If really built from a flake, dirty, if not built from flake, leave empty.

I thought it would work… - I might not have explained myself clearly: in your flake (wherever it is living) you should be able to add { system.configurationRevision = if self ? rev then self.rev else "dirty"; } to the modules array of your flake.nix system configuration (after the set of your system configuration / import configuration.nix). Only then it will show up in nixos-version. If that doesn’t work, I don’t know how to handle it… This seems to be the prefered way as described by Eelco Dolstra in the third part of a very recomendable series of blog posts about flakes.

Actually the code of nixos-version is a bit unlucky, since it ignores any unknown parameters (i.e. ones I just added) and just prints the version and codename by default. This makes implementing this feature also for older (i.e. current) versions more difficult, but I think I found a workaround. I will see, when I can test it…

1 Like

Indeed, after doing this:

diff --git a/hosts/tux-nixos.nix b/hosts/tux-nixos.nix
index 8b12c50..8b6f877 100644
--- a/hosts/tux-nixos.nix
+++ b/hosts/tux-nixos.nix
@@ -7,2 +7,4 @@
     (with self.nixosModules; [ cachix flake intel k3s gc ]) ++ [
+      (_: { system.configurationRevision = self.rev or "dirty"; })
+
       ./legacy/tux-nixos.nix

nixos-version does include the rev. I always thought this was automatically applied.

I agree, it seems a bit unintuitive, that it isn’t applied automatically…