Seeking guidance regarding system roll-back and switch-generation

[Chris Marusich]

Hi Ludo,

I have questions about the design of the mechanism by which GuixSD
switches from one operating system configuration to another.  I'm
emailing you directly because you have the most commits in this area of
the project, so I think you might be in the best position to answer.

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?

Below, I summarize the differences between the NixOS mechanism and the
GuixSD mechanism, and I describe two possible solutions for augmenting
the GuixSD mechanism to support system roll-back and switch-generation.
What solution do you think is best?

COMPARISON OF NIXOS AND GUIXSD MECHANISMS

In NixOS, to upgrade the system, one invokes 'nixos-rebuild switch'.
This performs the following steps in order: (1) build the system
configuration defined in /etc/nixos/configuration.nix, (2) flip the
system profile symlink, and (3) invoke the newly built system's
switch-to-configuration script, which (4) invokes the newly built
system's install-grub.sh script (which is a wrapper around the system's
install-grub.pl script), and (5) activates the new system.

The switch-to-configuration, install-grub.sh, and install-grub.pl
scripts are scripts that have been installed within each system
generation.  Whenever a new system configuration is built, these three
scripts are generated and installed within that system generation (e.g.,
at /nix/var/nix/profiles/system-5-link/bin/switch-to-configuration).
Because nix builds them at the same time it builds the system, nix knows
precisely which paths in the store these scripts need to do their jobs
(grub, kernel, initrd, etc.), and nix hard-codes these paths into the
generated scripts.  Thus, in general these scripts are unique for each
system generation, and each script knows precisely (and only) how to do
its job for its particular system generation.

In GuixSD, to upgrade the system, one invokes 'guix system reconfigure
config.scm'.  This performs the following steps in order: (1) build the
system configuration defined in config.scm, (2) flip the system profile
symlink, (3) run the new system's activation script, (4) install grub.

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.

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.  This would be a non-trivial change to the "guix
system" logic, but once we make that change, the implementation of
system roll-back and switch-generation would probably be pretty
straightforward.  This would also make GuixSD's design more similar to
the NixOS design, which might encourage cross-pollination between these
two similar projects.

SOLUTION 2: STORE THE OPERATING SYSTEM CONFIGURATION FILE

However, it may not be necessary to generate a "switch-to-configuration"
script at all.  Instead, what if we just stored the operating system
configuration file in a well known location within each system
generation?  This might enable us to re-use the existing "guix system"
code to implement roll-back and switch-generation.  This might also have
other nice benefits.  For example, it would leave a record of what the
previous system configurations were, and we could add a command like
"guix system diff" that could diff the operating system configuration
files for any two generations.  This might also eliminate the need to
store an activation script.  However, it could introduce a wrinkle: if
GuixSD does not understand how to read a particular system generation's
operating system configuration file (e.g., because the generation was
made by a version of GuixSD from the far past or far future which uses
an incompatible operating system file structure), then it would not be
able to switch to that generation.

Please let me know which solution you think is best.

Thank you,
-- 
Chris

signature.asc
Description: PGP signature