[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Seeking guidance regarding system roll-back and switch-generation
From: |
Ludovic Courtès |
Subject: |
Re: Seeking guidance regarding system roll-back and switch-generation |
Date: |
Mon, 18 Jul 2016 15:01:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hi Chris,
Chris Marusich <address@hidden> 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’.