Hi Chris, Chris Marusich <cmmarus...@gmail.com> skribis:
> I've noticed that the GuixSD mechanism is different from the NixOS > mechanism. In particular, NixOS uses an "install-grub" script (which is > specific to each system generation) to install grub, but GuixSD does > not. Is this difference intentional? Looking at <https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl>, part of it seems to be concerned with the generation of grub.cfg, which is what (gnu system grub) does. It also does a couple more things, such as providing proper EFI support, and avoiding reinstalling GRUB when possible (whereas ‘guix system reconfigure’ currently reruns ‘grub-install’ each time, even when it’s not strictly needed.) So I don’t think it’s very different, after all. Or am I missing something? > COMPARISON OF NIXOS AND GUIXSD MECHANISMS [...] > The GuixSD mechanism differs from the NixOS mechanism in a few ways. > The biggest difference is that GuixSD does not use a > "switch-to-configuration" script (although GuixSD does have a system > activation script, which activates the system but does not install the > bootloader). In NixOS, all activities involving a system configuration > switch - upgrade the system, roll back the system, switch the system to > an arbitrary, existing generation - use this script to install grub > and/or activate services. Because the scripts are generated at build > time and hard-coded with the paths to things like grub, the > 'nixos-rebuild' command does not need to concern itself with finding all > the right things; to install the right grub and activate the right > services for a particular system generation, the 'nixos-rebuild' command > just needs to invoke the switch-to-generation script for that > generation. This means that to perform rollback, the 'nixos-rebuild' > command does not need to know what the original operating system > configuration file was. Interesting, I forgot (or ignored!) these details about NixOS. :-) > SOLUTION 1: USE A SWITCH-TO-CONFIGURATION SCRIPT > > The current mechanism for installing grub and activating services in > GuixSD requires the presence of an operating system configuration file. > This makes it difficult to roll back or switch configurations, since we > do not currently store the operating system configuration files for > previous system configurations. One way to solve this problem is to > follow the NixOS example and generate a similar > "switch-to-configuration" script at system build time. Perhaps it could > be a gexp or something. Switching to a generations primarily means: (1) running the target’s activation script, (2) updating Shepherd services, and (3) updating grub.cfg. Of these (1) and (3) are currently easy to do on GuixSD. (Right? :-)) (2) is more difficult. It’s already difficult when switching to a *new* generation because we have to arrange to change the state of the currently-running PID 1 to get closer to its target state. It’s even more difficult when rolling back to a previous generation because, as we discussed, we currently don’t have any representation of the previous generation’s list of Shepherd services. When we discussed it previously, I said that we could add a purely declarative representation of Shepherd services in the output of ‘guix system build’ (just like we currently have a ‘parameters’ file.) A ‘switch-to-configuration’ script would essentially be an executable variant of that representation. However, I think I prefer the declarative approach (sexps to describe services) over the procedural approach (a ‘switch-to-configuration’ script), because it leaves more flexibility to the ‘guix system’ command and to the user, and also decouples things a bit more. Does that make sense? WDYT? > SOLUTION 2: STORE THE OPERATING SYSTEM CONFIGURATION FILE Won’t work, as Tobias notes. :-) Thank you for the detailed analysis! Ludo’.
