cc @jtojnar @grahamc

For what it's worth, was able to get my system back up and running after using the patch.

For this code path to be hit though, you essentially have to nuke your db.sqlite, then do nix-collect-garbage, then attempt to reinstall

or you could nix-store --delete a generation path

Successfully created backport PR #156331 for release-21.11.

This doesn't work as expected, gen is a 3-element tuple so .format(*gen, e) will expand to .format(gen[0], gen[1], gen[2], e). A simple fix would be to either remove the unpack operator (*) so that the full tuple is printed as-is (ugly), or use gen[0] to print only the profile name (cryptic).

That said, the best option is probably to make SystemIdentifier a NamedTuple, which will allow us to use gen.profile, gen.generation and gen.specialisation instead of gen[0], gen[1] and gen[2] respectively. This is exactly the change made by d6354030fa3542a6d604c3206b731f666be36485, proposed in #156798.

This doesn't work as expected, gen is a 3-element tuple so .format(*gen, e) will expand to .format(gen[0], gen[1], gen[2], e). A simple fix would be to either remove the unpack operator (*) so that the full tuple is printed as-is (ugly), or use gen[0] to print only the profile name (cryptic).

That said, the best option is probably to make SystemIdentifier a NamedTuple, which will allow us to use gen.profile, gen.generation and gen.specialisation instead of gen[0], gen[1] and gen[2] respectively. This is exactly the change made by d635403, proposed in #156798.

Yea, currently it looks like:

ignoring generation 'None' in the list of boot entries because of the following error:
1
ignoring generation 'None' in the list of boot entries because of the following error:
2
ignoring generation 'None' in the list of boot entries because of the following error:
3
ignoring generation 'None' in the list of boot entries because of the following error:
4
ignoring generation 'None' in the list of boot entries because of the following error:
5
ignoring generation 'None' in the list of boot entries because of the following error:
6

which hints at gen[0] is always None, and gen[1] is the generation number.

gen[0] is not always None, it should contain the name of the profile specified with the --profile-name/-p option when the generation was created with nixos-rebuild. gen[0] is None only if the option was not specified and thus the generation was created under the default system profile.

d6354030fa3542a6d604c3206b731f666be36485 handles this case and prints default profile instead of profile 'None'.

Quoting the nixos-rebuild man page:

--profile-name,  -p

Instead of using the Nix profile /nix/var/nix/profiles/system to keep track of the current and previous system configurations, use /nix/var/nix/profiles/system-profiles/name. When you use GRUB 2, for every system profile created with this flag, NixOS will create a submenu named “NixOS - Profile 'name'” in GRUB’s boot menu, containing the current and previous configurations of this profile.

For instance, if you want to test a configuration file named test.nix without affecting the default system profile, you would do:

$ nixos-rebuild switch -p test -I nixos-config=./test.nix

The new configuration will appear in the GRUB 2 submenu “NixOS - Profile 'test'”.

gen[0] is not always None,

Sorry, I meant, its always None in my current case. So it's not really meaningful.

Oh yes got it, indeed a plain 'None' is not very meaningful, and also the error printed is actually the generation number, which doesn't really help debugging to say the least 😅

What should we do now, revert this commit and merge #156798 (after review of course), or just merge #156798 on top of it after resolving the single-line conflict? Or maybe extract d6354030fa3542a6d604c3206b731f666be36485 from #156798 into another PR to more easily backport this single commit to 21.11 (no clue how and when to backport changes)?

It sounds like y'all already know, but this change masks the underlying OSError (in my case, it was ENOSPACE).