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

[Chris Marusich]

Hi Ludo,

Thank you very much for taking the time to respond!  Now I have a better
idea of how to proceed.

address@hidden (Ludovic Courtès) writes:

> 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?

Yes, they both install grub, but the mechanism seems different.  NixOS
generates a script for each system generation, which installs exactly
the right grub for that generation.  Unless I'm mistaken, GuixSD does
not do that.  Instead, the existing GuixSD mechanism seems to require an
operating system configuration file.  GuixSD uses that to determine the
correct grub, which it then installs.

>> 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.

In addition to (3), don't we also need to install the grub software
itself?  For Libreboot (or coreboot), I believe that the "payload grub"
[1] is installed in flash ROM via a mechanism that is outside the scope
of GuixSD.  However, for other systems, it's still necessary to install
the bootloader to some drive, e.g., /dev/sda, right?

[1] https://www.coreboot.org/Payloads

> Of these (1) and (3) are currently easy to do on GuixSD.  (Right? :-))

For both (1) and (3), the current GuixSD mechanism appears to require an
operating system configuration file.  Since roll-back and
switch-generation will not have such a file available, it seems the
existing mechanism won't work without some changes.

> (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?

Yes, I think that makes sense.  I need to learn more about GuixSD's
activation mechanism, but it makes sense that a procedural definition
(e.g., like in NixOS's switch-to-configuration script) is equivalent to
a declarative definition.  I think a declarative definition of services
would be fine.  Concretely speaking, is there a specific format that is
convenient to use for such a "declarative definition of services"?

What about the grub installation?  As mentioned earlier, NixOS
hard-codes stuff like the path to the kernel image and initrd into the
install-grub.pl script.  Are you suggesting that I store any necessary
information for installing grub in some kind of a declarative definition
in the output of "guix system build", similar to how we'd like to do it
for activation?  Or are you suggesting that I simply parse the output of
"guix system build" for well-known paths (e.g.,
/var/guix/profiles/system-3-link/initrd)?

Specifically, to complete the first milestone (flip symlinks and
regenerate grub.cfg), I need to determine the paths to certain things
like the kernel and the initrd for an arbitrary system generation.  So,
I'm not sure if I should simply parse that information from the file
system, or if I should try to use the store to obtain that information.
What are your thoughts?

>> SOLUTION 2: STORE THE OPERATING SYSTEM CONFIGURATION FILE
>
> Won’t work, as Tobias notes.  :-)
>
> Thank you for the detailed analysis!

OK, I won't do this.  Thank you for clarifying why it is a bad idea!
It's always good to save time not implementing stuff we don't need.

-- 
Chris

signature.asc
Description: PGP signature