From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Seeking guidance regarding system roll-back and switch-generation Date: Sun, 17 Jul 2016 02:22:36 -0700 Message-ID: <87twfo7h5v.fsf@gmail.com> 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]:47398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOiHh-0007cB-5N for guix-devel@gnu.org; Sun, 17 Jul 2016 05:22:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOiHd-0002Lq-PQ for guix-devel@gnu.org; Sun, 17 Jul 2016 05:22:49 -0400 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 Content-Transfer-Encoding: quoted-printable 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, =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXi05eAAoJEN1AmhXYIkadTfEP/jPi5wYlHPNlaQ7Fe6pjxnKv CzzFqpJQPIpmAqx2k0RjFyQZ8qOXIoXzCDf2xhO20M+4rTMrawLKzV9yx2PhqRdM WoHuB1s0H+WBzFrU8Vg++vQARbRTFci5JhhJ5ZujA4/qbJX2derNMrdjFOHhLP4N RgtE9+5TfYnZgepxiK85217LpWvZI/IZBIYZVoU2WBn8sQ5gerTxGTnc8Gi9dsuD Q5NcyeZ1E2sunP7yblYZGxZsUv8twZ87sCueZui/gcnnQFZCyhA6RcsmL6GqxjGj Ud+dK8EjUoWeEnf+BcJ7Qr7wWzx5VC2PWlQ37IY6PSQlA4dTlxU/BluUN6diiuOW 17cPFTwiis/yVd+9KNuvLZ32LBg43WtiozMIoOTf/lfv/gnPUaS3/UJCfMyqvijC JqH2yOUKFPuESxssXFTqO4txgG9dzxbeO+ng5Ooba/+1r6QFQ/C8J3vIqeCFgdy2 UZDfowwCxyyriYHhQGu6bLbrtb4YyZ3EOuwIrgB8fJxd6Kqs6HkvixMkVl0ICAqY Y2OJ/a8vb8Zbt+XNtrjS02j0Ea96YyzaRzeGFdYZLGKT5Ols+W/Mx6ROUOiYjdRO +J/nkwDXKLwN9esFakz4lb2xnM54tey9UBL3e5fo/6pxs1xBsxAbZ4epnxltg9gP BQqrH8YlDpSZsgw69V4G =+TGH -----END PGP SIGNATURE----- --=-=-=--