Nixpkgs: Delete systemConfig kernel parameter?

[nh2]

While working on booting my Chromebook, @grahamc, @cleverca22, @samueldr, @lheckemann and me noticed that lot of scripts (for example the bit that generates GRUB menuentrys) set the kernel parameter systemConfig=${config.system.build.toplevel} but nothing appears to use it.

We should find out what it was good for, when the last use case was removed, whether it's still desired and thus whether we should remove it everywhere.

Uses in nixpkgs commit 05a53ecd827c5910e34171e7681c56913b29add1:

% git grep systemConfig
nixos/modules/installer/cd-dvd/system-tarball-fuloong2f.nix:      init=/boot/init systemConfig=/boot/init ${toString config.boot.kernelParams}
nixos/modules/installer/cd-dvd/system-tarball-pc.nix:      append ip=dhcp nfsroot=/home/pcroot systemConfig=${config.system.build.toplevel} init=${config.system.build.toplevel}/init rw
nixos/modules/installer/cd-dvd/system-tarball-pc.nix:      append initrd=initrd ip=dhcp nfsroot=/home/pcroot systemConfig=${config.system.build.toplevel} init=${config.system.build.toplevel}/init rw
nixos/modules/misc/crashdump.nix:        --command-line="systemConfig=$(readlink -f /run/current-system) init=$(readlink -f /run/current-system/init) irqpoll maxcpus=1 reset_devices ${kernelParams}"
nixos/modules/profiles/docker-container.nix:    ln -fs $systemConfig/init /init
nixos/modules/system/activation/activation-script.nix:            systemConfig=@out@
nixos/modules/system/activation/activation-script.nix:            # The readlink is there to ensure that when $systemConfig = /system
nixos/modules/system/activation/activation-script.nix:            ln -sfn "$(readlink -f "$systemConfig")" /run/current-system
nixos/modules/system/activation/top-level.nix:      substituteInPlace $out/init --subst-var-by systemConfig $out
nixos/modules/system/boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh:    echo "  APPEND systemConfig=$path init=$path/init $extraParams"
nixos/modules/system/boot/loader/grub/install-grub.pl:        "systemConfig=" . Cwd::abs_path($path) . " " .
nixos/modules/system/boot/loader/init-script/init-script-builder.sh:      echo "export systemConfig=$(readlink -f $path)"
nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py:    kernel_params = "systemConfig=%s init=%s/init " % (generation_dir, generation_dir)
nixos/modules/system/boot/stage-2-init.sh:systemConfig=@systemConfig@
nixos/modules/system/boot/stage-2-init.sh:echo "booting system configuration $systemConfig" > /dev/kmsg
nixos/modules/system/boot/stage-2-init.sh:$systemConfig/activate
nixos/modules/system/boot/stage-2-init.sh:ln -sfn "$systemConfig" /run/booted-system
nixos/modules/virtualisation/lxc.nix:    systemConfig =
nixos/modules/virtualisation/lxc.nix:    environment.etc."lxc/lxc.conf".text = cfg.systemConfig;

[arianvp]

Did some archaeology. It was originally introduced in this commit https://github.com/NixOS/nixpkgs/commit/c10fe148a3d043dcb288117ad6385e7ec4e62957#diff-c27013ebbf59ccaa7c0c4b9ab9ca98f8

and was deleted in this commit https://github.com/NixOS/nixpkgs/commit/c4f910f55015b150bebe3d3ecdea76c1aa8bbcca#diff-54f05a2ce016b2d32c895218864e484c

It indeed seems to be unused
But note the commit message:

However, the GRUB menu
builder still needs to add `systemConfig' to the kernel command line
for compatibility with old configurations.

This was so that older generations on your system would still boot. Given that I think most of
us do not have to boot back to configurations from years ago, I think we can safely remove it now.

[alex-giusi-tiri]

I would like to have it kept, for backward-compatibility for those menu entries that actually need it, just in case (even if they are that old!). Please keep it!
However, there is an alternative option, I think: a Nix (/etc/nixos/configuration.nix) option could be created to indicate whether to include this boot parameter.
Or, perhaps, ideally, try to detect which entries need it.
However, even so, I would like to still keep the Nix option available.
I am thinking that two booleans would be enough:
Something like this:

• "enabled": to declare whether it would be added at all; and:
• "needed": to declare when it should be added: always, or only if needed.

I don't currently know everything which is involved in generating grub.cfg, but it seems that all the menu entries are regenerated each time grub.cfg is regenerated.
I don't know if all previous menu entries need to be regenerated as well (if things would break if not done), or if that's how it is at the moment.
If they do not need to be regenerated, and if it is possible to implement, then, I think that, ideally, only the new entry should be generated, and all the previous ones should be left unchanged (unless a NIx option and/or command-line option (overriding the Nix one) would be provided for nixos-rebuild).

I think that there could be new options (NIx and/or command-line) made if it is needed to regenerate previous menu entries (as preferred/required).

Or, perhaps (better?), integrate grub.cfg into the Nix store, and have /boot/grub/grub.cfg a (hard/symbolic) link? Is Grub able to read symbolic links? Or maybe have it a hard link? And, maybe have the grub.cfg in the store copied only when /boot is on a different partition (because a hard link does not work across filesystems)? ...and, there could be (Nix/command-line) options for that too...
(Or, fix Grub to be able to read symbolic links. Or, fix, if possible, to make a hard link across filesystems ...)

:-)

[stale[bot]]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[arianvp]

This is not stale

[xaverdh]

I would like to have it kept, for backward-compatibility for those menu entries that actually need it, just in case (even if they are that old!). Please keep it!
[...]

I think similar to how systemd breaking changes are handled with init-interface-version we could add a small file to new configurations, which tracks if we need to add systemConfig to the boot entry (maybe init-interface-version can be reused somehow?). The grub builder would then check if that file exists to determine whether it should add systemConfig.
Such a mechanism might become handy in the future as well, if the need should arise to make more changes.

[samueldr]

We're talking about a soon to be decade-old commit that removed that kernel command-line parameter.

I don't think backwards compatibility up to 2010 generations is expected, and it should be simply removed.

If anyone can show me their system with a genuine 2010-era NixOS generation, and updates through the different NixOS releases through the years, maybe it can sway me over somehow not making it a breaking change. Though as this stands, this looks to me like cruft that don't need to be "handled" at all; simply removing it should be safe.

At the very worst, a user that loses access to their 2010-era generations can rebuild from a 20.03 generation to get their menu items working.

[xaverdh]

At the very worst, a user that loses access to their 2010-era generations can rebuild from a 20.03 generation to get their menu items working.

Good point, but I guess this should at least be documented (in the release notes) then?

[samueldr]

Yes, since technically it _is_ a breaking change, it is a good idea to document it even if it is extremely unlikely to be an issue, if only to practice what we preach. Something along the lines of:

Starting with this release, generations requiring systemConfig to boot will not be bootable anymore. Such generations would be from September 2010 and earlier.