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’.
next prev 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).