unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Seeking guidance regarding system roll-back and switch-generation
Date: Fri, 22 Jul 2016 17:49:18 +0200	[thread overview]
Message-ID: <87vazxk70h.fsf@gnu.org> (raw)
In-Reply-To: <874m7mvxcz.fsf@gmail.com> (Chris Marusich's message of "Tue, 19 Jul 2016 01:35:40 -0700")

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Hi!

Chris Marusich <cmmarusich@gmail.com> skribis:

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

Sorry for the delay!  That’s what you get for asking difficult
questions.  ;-)

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Chris Marusich <cmmarusich@gmail.com> 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.

Sure, but it seems to be equivalent in the end.

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

In general yes (there are cases where this is not needed, but let’s
ignore them.)

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

The output of ‘guix system build’ contains the ‘parameters’ file, which
is enough to generate grub.cfg (see ‘previous-grub-entries’ in (guix
scripts system)).

However, the activation script is indeed missing.  We can add it to the
output of ‘guix system build’ by extending ‘system-service-type’:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 951 bytes --]

diff --git a/gnu/services.scm b/gnu/services.scm
index 5479bfa..fc3e17e 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -352,11 +352,18 @@ ACTIVATION-SCRIPT-TYPE."
 
 (define (second-argument a b) b)
 
+(define (gexps->activation-system-entry gexps)
+  "Return a directory entry to add to the result of the 'system' derivation."
+  (mlet %store-monad ((script (activation-script gexps)))
+    (return `(("activate" ,script)))))
+
 (define activation-service-type
   (service-type (name 'activate)
                 (extensions
                  (list (service-extension boot-service-type
-                                          gexps->activation-gexp)))
+                                          gexps->activation-gexp)
+                       (service-extension system-service-type
+                                          gexps->activation-system-entry)))
                 (compose append)
                 (extend second-argument)))
 

[-- Attachment #3: Type: text/plain, Size: 795 bytes --]


This way we have direct access to each generation’s activation script
and we should be fine with (3).

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

I would suggest an sexp as discussed at:

  https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00173.html

> What about the grub installation?

The ‘parameters’ file should be enough, as you wrote.

HTH!

Ludo’.

  parent reply	other threads:[~2016-07-22 15:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-17  9:22 Seeking guidance regarding system roll-back and switch-generation Chris Marusich
2016-07-17 15:27 ` Tobias Geerinckx-Rice
2016-07-18 12:39   ` Ludovic Courtès
2016-07-18 13:01 ` Ludovic Courtès
2016-07-19  8:35   ` Chris Marusich
2016-07-22 10:32     ` Chris Marusich
2016-07-22 15:49     ` Ludovic Courtès [this message]
2016-07-25  6:22       ` Chris Marusich
2016-07-25  8:06         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vazxk70h.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).