From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Seeking guidance regarding system roll-back and switch-generation Date: Mon, 18 Jul 2016 15:01:51 +0200 Message-ID: <87vb03nlq8.fsf@gnu.org> References: <87twfo7h5v.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bP8BO-0005P2-1F for guix-devel@gnu.org; Mon, 18 Jul 2016 09:02:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bP8BH-00017o-0g for guix-devel@gnu.org; Mon, 18 Jul 2016 09:02:01 -0400 In-Reply-To: <87twfo7h5v.fsf@gmail.com> (Chris Marusich's message of "Sun, 17 Jul 2016 02:22:36 -0700") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org Hi Chris, Chris Marusich 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 , 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 =E2=80=98guix system reconfigure=E2=80=99 currently reruns =E2=80=98grub-install=E2=80=99 each t= ime, even when it=E2=80=99s not strictly needed.) So I don=E2=80=99t think it=E2=80=99s very different, after all. Or am I m= issing 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=E2=80=99s 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=E2=80=99s already difficult when switching to a = *new* generation because we have to arrange to change the state of the currently-running PID=C2=A01 to get closer to its target state. It=E2=80=99s even more difficult when rolling back to a previous generation because, as we discussed, we currently don=E2=80=99t have any representatio= n of the previous generation=E2=80=99s 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 =E2=80=98g= uix system build=E2=80=99 (just like we currently have a =E2=80=98parameters=E2= =80=99 file.) A =E2=80=98switch-to-configuration=E2=80=99 script would essentially be an ex= ecutable variant of that representation. However, I think I prefer the declarative approach (sexps to describe services) over the procedural approach (a =E2=80=98switch-to-configuration= =E2=80=99 script), because it leaves more flexibility to the =E2=80=98guix system=E2= =80=99 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=E2=80=99t work, as Tobias notes. :-) Thank you for the detailed analysis! Ludo=E2=80=99.