Re: Seeking guidance regarding system roll-back and switch-generation

[ludo@gnu.org (Ludovic Courtès)]

Hi Chris,

Chris Marusich <cmmarusich@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’.