From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Seeking guidance regarding system roll-back and switch-generation Date: Tue, 19 Jul 2016 01:35:40 -0700 Message-ID: <874m7mvxcz.fsf@gmail.com> References: <87twfo7h5v.fsf@gmail.com> <87vb03nlq8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPQVO-0008AE-S7 for guix-devel@gnu.org; Tue, 19 Jul 2016 04:35:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPQVL-0003cd-W0 for guix-devel@gnu.org; Tue, 19 Jul 2016 04:35:53 -0400 In-Reply-To: <87vb03nlq8.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 18 Jul 2016 15:01:51 +0200") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, Thank you very much for taking the time to respond! Now I have a better idea of how to proceed. ludo@gnu.org (Ludovic Court=C3=A8s) writes: > 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= time, 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= 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=E2=80= =99s > 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=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 generati= on > because, as we discussed, we currently don=E2=80=99t have any representat= ion 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= =98guix > 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 = executable > 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-configuratio= n=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? 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=E2=80=99t 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXjeZfAAoJEN1AmhXYIkad95cQAJSoJx88VHIoM/31Fp90Ok45 9VTYiRp72wwIkEENCN160soghT5rKgjDpudXEz6wVQ0iFSEZTMH8C3clLCCqFcxL B9884oi4R9fDmUx++0QyWSNTRx1pZuOmJbH3s3Ox8Y7OsRzlNUa4ABxSQSGGkteC hYs6XHlHkrpqZ6Qb9NDS83N+/ZhPDHOFIPCowSH1EJKb2QrxEdA56xfGPLlRUYE+ nn9gSdHqoMpXidzqnBXVskDdkzPzBG4kEP9A2qrfBrEYPMJ4MP7iw8vO1Xj6M8Mf MrKwC1/WpigfXCnWaiZcIzJ4FDTe/2skqJ5gMWjzj8aFvAPBXU0rJGpqUPXbChyG R9C5LHGBeXt8ldGX2Qq3ydodEpbui/e5lSsSo8mX4veGyyt2CosDoLEicSl97i0h rcNcQbNPwcqC8+lmAXDwXXEZmz6YLWOzxPSofty/7/ssNoWQIGpnzNrVqH9fEtzF 1KsyBNlLr6/BoskVKuZaxV/IedTw0xnTyGf+nf+5uUNjNY7wMihPY5664oDgDruU WzLQHO4coi+A4IF+8XbYpJczdjrY3xj9lrBfw/4D62snp2u524Ng77dcZfOe5Gmr YpKodxZvaInVKrXazz0hEm8prOVHKEkwxBIO1vA52/Ed14AsVi4tXfxFdfEOz9O9 ImV+2+2QbqLk2NZXFKzQ =NGnk -----END PGP SIGNATURE----- --=-=-=--