bug#27007: boot-parameters are not documented

bug#27007: boot-parameters are not documented

[Tomáš Čech]

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

I'm running from GIT with HEAD on 12eecbf0bb798f99454a46c191bb0ec6bdef1aa5.

It seems that menu-entry is still described in documentation

doc/guix.texi:15337

but code seems to abandon the use already in favor of boot-parameters
at least to my level of understanding.

My question without answer is - how can I specify bootloader menu entries now?

TIA,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27007: boot-parameters are not documented

[Mathieu Othacehe]

Hi Tomáš,

> My question without answer is - how can I specify bootloader menu entries now?

You're right, you have to pass a <boot-parameters> now. The
documentation patch is still in review, you can find it here :

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#489

The example has been updated :

--8<---------------cut here---------------start------------->8---
 @example
-(menu-entry
+(boot-parameters
   (label "The Other Distro")
-  (linux "/boot/old/vmlinux-2.6.32")
-  (linux-arguments '("root=/dev/sda2"))
+  (root-device "my-root")
+  (boot-name 'grub)
+  (store-device "my-root")
+  (store-mount-point "/")
+  (kernel "/boot/old/vmlinux-2.6.32")
+  (kernel-arguments '("root=/dev/sda2"))
   (initrd "/boot/old/initrd"))
 @end example
--8<---------------cut here---------------end--------------->8---

It will maybe change again in the future, I'm not sure <boot-parameters>
are our best option here.

Anyway, let me now if it works for you.

Thanks,

Mathieu

bug#27007: boot-parameters are not documented

[Danny Milosavljevic]

Hi,

there's a doc patch in review by Mathieu (16 May 2017 15:03 +0200, "doc: Adapt to multiple bootloader support", bug# 26339) in guix-patches.

Although I wonder what menu-entries can be used for.  What are you using it for?

bug#27007: boot-parameters are not documented

[Tomáš Čech]

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

On Sat, May 20, 2017 at 10:52:34PM +0200, Danny Milosavljevic wrote:
>Hi,
>
>there's a doc patch in review by Mathieu (16 May 2017 15:03 +0200, "doc: Adapt to multiple bootloader support", bug# 26339) in guix-patches.

As I have seen this feature on ML some time ago already, I didn't
expect to be in between acceptance of both patches. Sorry.


>Although I wonder what menu-entries can be used for.  What are you using it for?
>

Defining other operating system entry:

 (menu-entry
  (label "openSUSE")
  (linux "(hd0,msdos1)/vmlinuz")
  (linux-arguments (list  "root=/dev/penguin/opensuse"  "init=/usr/lib/systemd/systemd"))
  (initrd "(hd0,msdos1)/initrd"))))))


Best regards,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27007: boot-parameters are not documented

[Leo Famulari]

On Sat, May 20, 2017 at 10:31:59PM +0200, Mathieu Othacehe wrote:
> 
> Hi Tomáš,
> 
> > My question without answer is - how can I specify bootloader menu entries now?
> 
> You're right, you have to pass a <boot-parameters> now. The
> documentation patch is still in review, you can find it here :
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#489

Okay. Generally, I think changes that affect users should be pushed with
documentation, even if we plan to change things again soon. The master
branch should always be "deployable". If we need to experiment with big
changes, we can do it on another branch.

bug#27007: boot-parameters are not documented

[Tomáš Čech]

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

On Sat, May 20, 2017 at 10:31:59PM +0200, Mathieu Othacehe wrote:
>
>Hi Tomáš,
>
>> My question without answer is - how can I specify bootloader menu entries now?
>
>You're right, you have to pass a <boot-parameters> now. The
>documentation patch is still in review, you can find it here :
>
>https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#489
>
>The example has been updated :
>
>--8<---------------cut here---------------start------------->8---
> @example
>-(menu-entry
>+(boot-parameters
>   (label "The Other Distro")
>-  (linux "/boot/old/vmlinux-2.6.32")
>-  (linux-arguments '("root=/dev/sda2"))
>+  (root-device "my-root")
>+  (boot-name 'grub)
>+  (store-device "my-root")
>+  (store-mount-point "/")
>+  (kernel "/boot/old/vmlinux-2.6.32")
>+  (kernel-arguments '("root=/dev/sda2"))
>   (initrd "/boot/old/initrd"))
> @end example
>--8<---------------cut here---------------end--------------->8---
>
>It will maybe change again in the future, I'm not sure <boot-parameters>
>are our best option here.

It's a bit complicated but much more flexible compared to
menu-entry. 'store-device' and 'store-mount-point' are Guix-centric
parameters and it is not obvious how to configure it for distributions
with kernel and initrd in /boot.


>Anyway, let me now if it works for you.

After following these changes I'm able to build system again. I'll
check the result GRUB configuration and report issue if there is one.

Thanks for your help,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27007: boot-parameters are not documented

[Ludovic Courtès]

Hi!

Tomáš Čech <sleep_walker@gnu.org> skribis:

> Defining other operating system entry:
>
> (menu-entry
>  (label "openSUSE")
>  (linux "(hd0,msdos1)/vmlinuz")
>  (linux-arguments (list  "root=/dev/penguin/opensuse"  "init=/usr/lib/systemd/systemd"))
>  (initrd "(hd0,msdos1)/initrd"))))))

I think <menu-entry> is the right abstraction level for this use case;
<boot-parameters> may be overkill for that.

To me <boot-parameters> was an internal thing, I didn’t understand we
were going to expose it.  Can’t we keep exposing ‘menu-entry’?  We’ll
probably have support the ‘menu-entry’ form for backward-compatibility
reasons at least.

Thoughts?

Thanks,
Ludo’.

bug#27007: boot-parameters are not documented

[Mathieu Othacehe]

Hi Ludo,

Since the rework, <menu-entry> are in (gnu bootloader grub). They can no
longer be used in menu-entries field of <bootloader-configuration>.

The <boot-parameters> is used instead. <boot-parameters> and
<menu-entry> are very similar though.

What we can do here is :

* Give <boot-parameters> default values as per <menu-entry> (as proposed
by Danny in doc patch review).
* Rename "menu-entries" field of <bootloader-configuration> to something
not so GRUB related, such as "entries" or "custom-entries".
* Maybe also remove <menu-entry> from (gnu bootloader grub) and use
<boot-parameters> directly as in (gnu bootloader extlinux).

WDYT ?

Thanks,

Mathieu

bug#27007: boot-parameters are not documented

[Ludovic Courtès]

Heya!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> Since the rework, <menu-entry> are in (gnu bootloader grub). They can no
> longer be used in menu-entries field of <bootloader-configuration>.
>
> The <boot-parameters> is used instead. <boot-parameters> and
> <menu-entry> are very similar though.

So how does the ‘menu-entry’ example that Tomáš gave translate with this
new API?  (Apologies for asking, I admit I haven’t fully adjusted to the
new API mentally.  :-))

> What we can do here is :
>
> * Give <boot-parameters> default values as per <menu-entry> (as proposed
> by Danny in doc patch review).

Sounds good in general, as long as we have default values that make
sense.

> * Rename "menu-entries" field of <bootloader-configuration> to something
> not so GRUB related, such as "entries" or "custom-entries".

Can we assume that all the bootloaders have a notion of “menu” and “menu
entries”?  Or do you think that very notion is not shared by all of
them?

> * Maybe also remove <menu-entry> from (gnu bootloader grub) and use
> <boot-parameters> directly as in (gnu bootloader extlinux).

Sure; having the implementations in (gnu bootloader xyz) follow the same
model sounds like a good idea.

Thank you!

Ludo’.

bug#27007: boot-parameters are not documented

[Mathieu Othacehe]

Hello,

> So how does the ‘menu-entry’ example that Tomáš gave translate with this
> new API?  (Apologies for asking, I admit I haven’t fully adjusted to the
> new API mentally.  :-))

Well it's still moving :)

We can ask him but I guess something like that :

--8<---------------cut here---------------start------------->8---
(boot-parameters
  (label "openSUSE")
  (root-device #f)
  (boot-name 'grub)
  (store-device #f)
  (store-mount-point "/")
  (kernel "(hd0,msdos1)/vmlinuz")
  (kernel-arguments (list  "root=/dev/penguin/opensuse"  "init=/usr/lib/systemd/systemd"))
  (initrd "(hd0,msdos1)/initrd"))
--8<---------------cut here---------------end--------------->8---

Note that root-device, boot-name, store-device and store-mount-point are
useless here.

> Sounds good in general, as long as we have default values that make
> sense.

Ok.

> Can we assume that all the bootloaders have a notion of “menu” and “menu
> entries”?  Or do you think that very notion is not shared by all of
> them?

We can suppose that it's always possible to add custom entries to
generated bootloader configuration. That would allow someone switching
from grub to extlinux to keep his custom entries.

> Sure; having the implementations in (gnu bootloader xyz) follow the same
> model sounds like a good idea.

Ok !

Thanks,

Mathieu

bug#27007: boot-parameters are not documented

[Tomáš Čech]

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

On Tue, May 23, 2017 at 11:31:12AM +0200, Mathieu Othacehe wrote:
>
>Hello,
>
>> So how does the ‘menu-entry’ example that Tomáš gave translate with this
>> new API?  (Apologies for asking, I admit I haven’t fully adjusted to the
>> new API mentally.  :-))
>
>Well it's still moving :)
>
>We can ask him but I guess something like that :
>
>--8<---------------cut here---------------start------------->8---
>(boot-parameters
>  (label "openSUSE")
>  (root-device #f)
>  (boot-name 'grub)
>  (store-device #f)
>  (store-mount-point "/")
>  (kernel "(hd0,msdos1)/vmlinuz")
>  (kernel-arguments (list  "root=/dev/penguin/opensuse"  "init=/usr/lib/systemd/systemd"))
>  (initrd "(hd0,msdos1)/initrd"))
>--8<---------------cut here---------------end--------------->8---
>
>Note that root-device, boot-name, store-device and store-mount-point are
>useless here.

I came with something similar:

 (boot-parameters
  (label "openSUSE")
  (root-device "/dev/penguin/opensuse")
  (boot-name 'grub)
  (store-device "(hd0,msdos1)")
  (store-mount-point "/")
  (kernel "(hd0,msdos1)/vmlinuz")
  (kernel-arguments '("root=/dev/penguin/opensuse"
                     "init=/usr/lib/systemd/systemd"))
  (initrd "(hd0,msdos1)/initrd"))))))

Unfortunately useless entries were still required (I didn't have that
idea with setting them to #f).

I couldn't verify the result configuration yet as I'm facing another,
unrelated problem.

Thanks,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27007: boot-parameters are not documented

[Ludovic Courtès]

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> We can ask him but I guess something like that :
>
> (boot-parameters
>   (label "openSUSE")
>   (root-device #f)
>   (boot-name 'grub)
>   (store-device #f)
>   (store-mount-point "/")
>   (kernel "(hd0,msdos1)/vmlinuz")
>   (kernel-arguments (list  "root=/dev/penguin/opensuse"  "init=/usr/lib/systemd/systemd"))
>   (initrd "(hd0,msdos1)/initrd"))
>
> Note that root-device, boot-name, store-device and store-mount-point are
> useless here.

I see.  The fact that there are these extra fields that are hard to
grasp as an external user of the API makes me thing that something
simpler like ‘menu-entry’ still makes sense for users.  (Of course
<boot-parameters> is the right thing to use internally, no argument
here.)

Concretely, I imagine the user-facing API would remain similar in
spirit; users would write

  (operating-system
    ;; …
    (bootloader (bootloader-configuration
                  ;; …
                  ;; Provide custom/extra menu entries here:
                  (entries (list (menu-entry …))))))

and those entries would be “lowered” to <boot-parameters> somewhere.
That way we’d provide the abstraction level that users may expect (“how
do I add a menu entry for my other distro?”) and at the same time reduce
the risk of mistakes (“I didn’t what to put in ‘store-device’ I put my
pet’s name there”).

WDYT?  :-)

>> Sounds good in general, as long as we have default values that make
>> sense.
>
> Ok.
>
>> Can we assume that all the bootloaders have a notion of “menu” and “menu
>> entries”?  Or do you think that very notion is not shared by all of
>> them?
>
> We can suppose that it's always possible to add custom entries to
> generated bootloader configuration. That would allow someone switching
> from grub to extlinux to keep his custom entries.

OK, sounds good.

Thanks,
Ludo’.

bug#27007: boot-parameters are not documented

[Mathieu Othacehe]

> and those entries would be “lowered” to <boot-parameters> somewhere.
> That way we’d provide the abstraction level that users may expect (“how
> do I add a menu entry for my other distro?”) and at the same time reduce
> the risk of mistakes (“I didn’t what to put in ‘store-device’ I put my
> pet’s name there”).
>
> WDYT?  :-)
>

It seems fine ! So to summarize, <menu-entry> would be moved to (gnu
bootloader). A procedure menu-entry->boot-parameters would assure
the mapping in (gnu bootloader).

Each booloader in (gnu bootloader xxx), would add
bootloader-configuration-menu-entries to generated entries.

I'll be afk for a week, but I'll submit a patch and the updated
documentation for this point when coming back.

Thanks for your fast answers :)

Mathieu

bug#27007: boot-parameters are not documented

[Ludovic Courtès]

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> and those entries would be “lowered” to <boot-parameters> somewhere.
>> That way we’d provide the abstraction level that users may expect (“how
>> do I add a menu entry for my other distro?”) and at the same time reduce
>> the risk of mistakes (“I didn’t what to put in ‘store-device’ I put my
>> pet’s name there”).
>>
>> WDYT?  :-)
>>
>
> It seems fine ! So to summarize, <menu-entry> would be moved to (gnu
> bootloader). A procedure menu-entry->boot-parameters would assure
> the mapping in (gnu bootloader).
>
> Each booloader in (gnu bootloader xxx), would add
> bootloader-configuration-menu-entries to generated entries.
>
> I'll be afk for a week, but I'll submit a patch and the updated
> documentation for this point when coming back.

Sounds like a good plan, thank you!

Ludo’.

bug#27007: boot-parameters are not documented

[Danny Milosavljevic]

On Tue, 23 May 2017 10:13:11 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> Can we assume that all the bootloaders have a notion of “menu” and “menu
> entries”? 

I think so.

But there are bootloaders that [also can] do the traditional thing: When you select an entry, it can chainload the bootsector of that partition.  For example Grub can do that.  We don't support that use case yet.  Grub can also load Windows NT bootloader directly or chainload an UEFI file etcetc - there are actually a lot of different kinds of "menu entries" even with the same bootloader.

See also <https://wiki.gentoo.org/wiki/GRUB2/Chainloading>.

It's just a question of what of all that stuff we want to support (as in maintain).

bug#27007: boot-parameters are not documented

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Tue, 23 May 2017 10:13:11 +0200 ludo@gnu.org (Ludovic Courtès)
> wrote:
>> Can we assume that all the bootloaders have a notion of “menu” and
>> “menu entries”?
>
> I think so.
>
> But there are bootloaders that [also can] do the traditional thing:
> When you select an entry, it can chainload the bootsector of that
> partition.  For example Grub can do that.  We don't support that use
> case yet.  Grub can also load Windows NT bootloader directly or
> chainload an UEFI file etcetc - there are actually a lot of different
> kinds of "menu entries" even with the same bootloader.

Right, but this is about the content of the menu entry.  If we want to
support that, we can provide an “escape hatch” in the ‘menu-entry’
object, which would be a string that goes as-is in the bootloader’s
config file.

I wonder if we should support everything you mention though.  OTOH it
would not feel right if we can’t load other free operating systems like
FreeBSD, etc.  Maybe we should just start with support for GNU variants
only and improve it later as people ask for it.

Thoughts?

Ludo’.

bug#27007: boot-parameters are not documented

[ng0]

On Fri, 26 May 2017 10:47:02 +0200, ludo@gnu.org (Ludovic Courtès) wrote:

> Danny Milosavljevic <dannym@scratchpost.org> skribis:
> 
> > On Tue, 23 May 2017 10:13:11 +0200 ludo@gnu.org (Ludovic Courtès)
> > wrote:
> >> Can we assume that all the bootloaders have a notion of “menu” and
> >> “menu entries”?
> >
> > I think so.
> >
> > But there are bootloaders that [also can] do the traditional thing:
> > When you select an entry, it can chainload the bootsector of that
> > partition.  For example Grub can do that.  We don't support that use
> > case yet.  Grub can also load Windows NT bootloader directly or
> > chainload an UEFI file etcetc - there are actually a lot of different
> > kinds of "menu entries" even with the same bootloader.
> 
> Right, but this is about the content of the menu entry.  If we want to
> support that, we can provide an “escape hatch” in the ‘menu-entry’
> object, which would be a string that goes as-is in the bootloader’s
> config file.
> 
> I wonder if we should support everything you mention though.  OTOH it
> would not feel right if we can’t load other free operating systems like
> FreeBSD, etc.  Maybe we should just start with support for GNU variants
> only and improve it later as people ask for it.
> 
> Thoughts?
> 
> Ludo’.


I think it's a matter of freedom of choice that we support all systems unconditionally
if they exist on the system the person uses.
We can start with GNU systems but should add support for everything afterwards,
no matter if people ask or not. Maybe they can't ask because they don't know what
is wrong and they just assume that their old system is now gone and they can not
dualboot as they assumed.

bug#27007: [PATCH 0/2] Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

Hi,

Here's the patch to use menu-entry instead of boot-parameters to define
custom bootloaders entries as discussed.

The second patch is the updated documentation for bootloader rework.

Thanks,

Mathieu

Mathieu Othacehe (2):
  bootloader: Use menu-entry to define custom bootloader entries.
  doc: Adapt to multiple bootloader support.

 doc/guix.texi               | 164 ++++++++++++++++++++++++--------------------
 gnu/bootloader.scm          |  29 +++++++-
 gnu/bootloader/extlinux.scm |   3 +-
 gnu/bootloader/grub.scm     |  62 ++++++-----------
 gnu/system.scm              |  14 ++++
 5 files changed, 156 insertions(+), 116 deletions(-)

-- 
2.13.0

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

* gnu/bootloader.scm (<menu-entry>): New variable. Export associated getters,
This record is extracted from grub module.
* gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use
  menu-entry->boot-parameters to convert menu-entry records to
  boot-parameters.
* gnu/bootloader/grub.scm (<menu-entry>): Remove.
(boot-parameters->menu-entry): Remove.
(grub-configuration-file): Use boot-parameters to create configuration
entries.
* gnu/system.scm (menu-entry->boot-parameters): New exported procedure.
---
 gnu/bootloader.scm          | 29 ++++++++++++++++++++-
 gnu/bootloader/extlinux.scm |  3 ++-
 gnu/bootloader/grub.scm     | 62 +++++++++++++++------------------------------
 gnu/system.scm              | 14 ++++++++++
 4 files changed, 65 insertions(+), 43 deletions(-)

diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm
index 4e77974d3..dfce2e2df 100644
--- a/gnu/bootloader.scm
+++ b/gnu/bootloader.scm
@@ -23,7 +23,16 @@
   #:use-module (guix records)
   #:use-module (guix ui)
   #:use-module (srfi srfi-1)
-  #:export (bootloader
+  #:export (menu-entry
+            menu-entry?
+            menu-entry-label
+            menu-entry-device
+            menu-entry-device-mount-point
+            menu-entry-linux
+            menu-entry-linux-arguments
+            menu-entry-initrd
+
+            bootloader
             bootloader?
             bootloader-name
             bootloader-package
@@ -50,6 +59,24 @@
 
 \f
 ;;;
+;;; Menu-entry record.
+;;;
+
+(define-record-type* <menu-entry>
+  menu-entry make-menu-entry
+  menu-entry?
+  (label           menu-entry-label)
+  (device          menu-entry-device       ; file system uuid, label, or #f
+                   (default #f))
+  (device-mount-point menu-entry-device-mount-point
+                      (default "/"))
+  (linux           menu-entry-linux)
+  (linux-arguments menu-entry-linux-arguments
+                   (default '()))          ; list of string-valued gexps
+  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp
+
+\f
+;;;
 ;;; Bootloader record.
 ;;;
 
diff --git a/gnu/bootloader/extlinux.scm b/gnu/bootloader/extlinux.scm
index 67b8815d4..0a1263aed 100644
--- a/gnu/bootloader/extlinux.scm
+++ b/gnu/bootloader/extlinux.scm
@@ -37,7 +37,8 @@
 corresponding to old generations of the system."
 
   (define all-entries
-    (append entries (bootloader-configuration-menu-entries config)))
+    (append entries (map menu-entry->boot-parameters
+                         (bootloader-configuration-menu-entries config))))
 
   (define (boot-parameters->gexp params)
     (let ((label (boot-parameters-label params))
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 49616b716..2ea2bb69a 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -103,19 +103,6 @@ denoting a file name."
    (color-highlight '((fg . yellow) (bg . black)))
    (color-normal    '((fg . light-gray) (bg . black))))) ;XXX: #x303030
 
-(define-record-type* <menu-entry>
-  menu-entry make-menu-entry
-  menu-entry?
-  (label           menu-entry-label)
-  (device          menu-entry-device       ; file system uuid, label, or #f
-                   (default #f))
-  (device-mount-point menu-entry-device-mount-point
-                      (default "/"))
-  (linux           menu-entry-linux)
-  (linux-arguments menu-entry-linux-arguments
-                   (default '()))          ; list of string-valued gexps
-  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp
-
 \f
 ;;;
 ;;; Background image & themes.
@@ -312,16 +299,6 @@ code."
         (#f
          #~(format #f "search --file --set ~a" #$file)))))
 
-(define (boot-parameters->menu-entry conf)
-  "Convert a <boot-parameters> instance to a corresponding <menu-entry>."
-  (menu-entry
-   (label (boot-parameters-label conf))
-   (device (boot-parameters-store-device conf))
-   (device-mount-point (boot-parameters-store-mount-point conf))
-   (linux (boot-parameters-kernel conf))
-   (linux-arguments (boot-parameters-kernel-arguments conf))
-   (initrd (boot-parameters-initrd conf))))
-
 (define* (grub-configuration-file config entries
                                   #:key
                                   (system (%current-system))
@@ -331,33 +308,36 @@ code."
 STORE-FS, a <file-system> object.  OLD-ENTRIES is taken to be a list of menu
 entries corresponding to old generations of the system."
   (define all-entries
-    (map boot-parameters->menu-entry
-         (append entries
-                 (bootloader-configuration-menu-entries config))))
-
-  (define entry->gexp
-    (match-lambda
-     (($ <menu-entry> label device device-mount-point
-                      linux arguments initrd)
+    (append entries (map menu-entry->boot-parameters
+                         (bootloader-configuration-menu-entries config))))
+
+  (define (boot-parameters->gexp params)
+    (let ((device (boot-parameters-store-device params))
+          (device-mount-point (boot-parameters-store-mount-point params))
+          (label (boot-parameters-label params))
+          (kernel (boot-parameters-kernel params))
+          (arguments (boot-parameters-kernel-arguments params))
+          (initrd (boot-parameters-initrd params)))
       ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
-      ;; Use the right file names for LINUX and INITRD in case
+      ;; Use the right file names for KERNEL and INITRD in case
       ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
       ;; separate partition.
-      (let ((linux  (strip-mount-point device-mount-point linux))
-            (initrd (strip-mount-point device-mount-point initrd)))
+      (let ((kernel  (strip-mount-point device-mount-point kernel))
+            (initrd  (strip-mount-point device-mount-point initrd)))
         #~(format port "menuentry ~s {
   ~a
   linux ~a ~a
   initrd ~a
 }~%"
                   #$label
-                  #$(grub-root-search device linux)
-                  #$linux (string-join (list #$@arguments))
-                  #$initrd)))))
+                  #$(grub-root-search device kernel)
+                  #$kernel (string-join (list #$@arguments))
+                  #$initrd))))
 
   (mlet %store-monad ((sugar (eye-candy config
-                                        (menu-entry-device (first all-entries))
-                                        (menu-entry-device-mount-point
+                                        (boot-parameters-store-device
+                                         (first all-entries))
+                                        (boot-parameters-store-mount-point
                                          (first all-entries))
                                         #:system system
                                         #:port #~port)))
@@ -374,12 +354,12 @@ set default=~a
 set timeout=~a~%"
                     #$(bootloader-configuration-default-entry config)
                     #$(bootloader-configuration-timeout config))
-            #$@(map entry->gexp all-entries)
+            #$@(map boot-parameters->gexp all-entries)
 
             #$@(if (pair? old-entries)
                    #~((format port "
 submenu \"GNU system, old configurations...\" {~%")
-                      #$@(map entry->gexp (map boot-parameters->menu-entry old-entries))
+                      #$@(map boot-parameters->gexp old-entries)
                       (format port "}~%"))
                    #~()))))
 
diff --git a/gnu/system.scm b/gnu/system.scm
index 0076f2fcb..96ef06a48 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -112,6 +112,7 @@
             boot-parameters-initrd
             read-boot-parameters
             read-boot-parameters-file
+            menu-entry->boot-parameters
 
             local-host-aliases
             %setuid-programs
@@ -299,6 +300,19 @@ The object has its kernel-arguments extended in order to make it bootable."
                                                      system
                                                      root-device)))
       #f)))
+
+(define (menu-entry->boot-parameters menu-entry)
+  "Convert a <menu-entry> instance to a corresponding <boot-parameters>."
+  (boot-parameters
+   (label (menu-entry-label menu-entry))
+   (root-device #f)
+   (boot-name 'custom)
+   (store-device (menu-entry-device menu-entry))
+   (store-mount-point (menu-entry-device-mount-point menu-entry))
+   (kernel (menu-entry-linux menu-entry))
+   (kernel-arguments (menu-entry-linux-arguments menu-entry))
+   (initrd (menu-entry-initrd menu-entry))))
+
 \f
 ;;;
 ;;; Services.
-- 
2.13.0

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Mathieu Othacehe]

* doc/guix.texi (GRUB configuration): Rename to "Bootloader
  configuration".
  Adapt occurences of "GRUB" in other sections.
---
 doc/guix.texi | 164 ++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 91 insertions(+), 73 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0f2c11bd3..e7bca4719 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -199,7 +199,7 @@ System Configuration
 * X.509 Certificates::          Authenticating HTTPS servers.
 * Name Service Switch::         Configuring libc's name service switch.
 * Initial RAM Disk::            Linux-Libre bootstrapping.
-* GRUB Configuration::          Configuring the boot loader.
+* Bootloader Configuration::    Configuring the boot loader.
 * Invoking guix system::        Instantiating a system configuration.
 * Running GuixSD in a VM::      How to run GuixSD in a virtual machine.
 * Defining Services::           Adding new service definitions.
@@ -7766,7 +7766,7 @@ instance to support new system services.
 * X.509 Certificates::          Authenticating HTTPS servers.
 * Name Service Switch::         Configuring libc's name service switch.
 * Initial RAM Disk::            Linux-Libre bootstrapping.
-* GRUB Configuration::          Configuring the boot loader.
+* Bootloader Configuration::    Configuring the boot loader.
 * Invoking guix system::        Instantiating a system configuration.
 * Running GuixSD in a VM::      How to run GuixSD in a virtual machine.
 * Defining Services::           Adding new service definitions.
@@ -7949,7 +7949,7 @@ system, should you ever need to.
 Speaking of roll-back, each time you run @command{guix system
 reconfigure}, a new @dfn{generation} of the system is created---without
 modifying or deleting previous generations.  Old system generations get
-an entry in the GRUB boot menu, allowing you to boot them in case
+an entry in the bootloader boot menu, allowing you to boot them in case
 something went wrong with the latest generation.  Reassuring, no?  The
 @command{guix system list-generations} command lists the system
 generations available on disk.  It is also possible to roll back the
@@ -8005,7 +8005,7 @@ List of strings or gexps representing additional arguments to pass on
 the command-line of the kernel---e.g., @code{("console=ttyS0")}.
 
 @item @code{bootloader}
-The system bootloader configuration object.  @xref{GRUB Configuration}.
+The system bootloader configuration object.  @xref{Bootloader Configuration}.
 
 @item @code{initrd} (default: @code{base-initrd})
 @cindex initrd
@@ -15674,32 +15674,50 @@ upon booting.  All the derivations referenced by @var{exp} are
 automatically copied to the initrd.
 @end deffn
 
-@node GRUB Configuration
-@subsection GRUB Configuration
+@node Bootloader Configuration
+@subsection Bootloader Configuration
 
-@cindex GRUB
+@cindex Bootloader
 @cindex boot loader
 
-The operating system uses GNU@tie{}GRUB as its boot loader
-(@pxref{Overview, overview of GRUB,, grub, GNU GRUB Manual}).  It is
-configured using a @code{grub-configuration} declaration.  This data type
-is exported by the @code{(gnu system grub)} module and described below.
+The operating system supports multiple bootloaders. The bootloader is
+configured using @code{bootloader-configuration} declaration. All the
+fields of this structure are bootloader agnostic except for one field,
+@code{bootloader} that indicates the bootloader to be configured and
+installed.
 
-@deftp {Data Type} grub-configuration
-The type of a GRUB configuration declaration.
+Note that all fields of @code{bootloader-configuration} are not
+necessarily handled by all GuixSD supported bootloaders.
+
+@deftp {Data Type} bootloader-configuration
+The type of a bootloader configuration declaration.
 
 @table @asis
 
+@item @code{bootloader}
+@cindex EFI, bootloader
+@cindex UEFI, bootloader
+@cindex BIOS, bootloader
+The bootloader to use, as a @code{bootloader} object. For now
+@code{grub-bootloader}, @code{grub-efi-bootloader} and
+@code{extlinux-bootloader} are supported.  @code{grub-efi-bootloader},
+allows to boot on modern systems using the @dfn{Unified Extensible
+Firmware Interface} (UEFI).
+
+Available bootloaders are described in @code{(gnu bootloader @dots{})}
+modules.
+
 @item @code{device}
 This is a string denoting the boot device.  It must be a device name
-understood by the @command{grub-install} command, such as
-@code{/dev/sda} or @code{(hd0)} (@pxref{Invoking grub-install,,, grub,
+understood by the bootloader @command{installer} command, such as
+@code{/dev/sda} or @code{(hd0)} (for GRUB, @pxref{Invoking grub-install,,, grub,
 GNU GRUB Manual}).
 
 @item @code{menu-entries} (default: @code{()})
 A possibly empty list of @code{menu-entry} objects (see below), denoting
-entries to appear in the GRUB boot menu, in addition to the current
+entries to appear in the bootloader menu, in addition to the current
 system entry and the entry pointing to previous system generations.
+generations.
 
 @item @code{default-entry} (default: @code{0})
 The index of the default boot menu entry.  Index 0 is for the entry of the
@@ -15709,42 +15727,37 @@ current system.
 The number of seconds to wait for keyboard input before booting.  Set to
 0 to boot immediately, and to -1 to wait indefinitely.
 
-@item @code{theme} (default: @var{%default-theme})
-The @code{grub-theme} object describing the theme to use.
-
-@item @code{grub} (default: @code{grub})
-@cindex EFI, bootloader
-@cindex UEFI, bootloader
-@cindex BIOS, bootloader
-The GRUB package to use.  Currently either @code{grub}, for ``legacy''
-x86 BIOS systems, or @code{grub-efi}, for modern systems using the
-@dfn{Unified Extensible Firmware Interface} (UEFI).
+@item @code{theme} (default: @var{#f})
+The bootloader theme object describing the theme to use. If no theme
+is provided, some bootloaders might use a default theme, that's true
+for GRUB.
 
 @item @code{terminal-outputs} (default: @code{'gfxterm})
-The output terminals used for the GRUB boot menu, as a list of symbols.
-These values are accepted: @code{console}, @code{serial},
-@code{serial_@{0-3@}}, @code{gfxterm}, @code{vga_text}, @code{mda_text},
-@code{morse}, and @code{pkmodem}.  This field corresponds to the GRUB
-variable GRUB_TERMINAL_OUTPUT (@pxref{Simple configuration,,, grub,GNU
-GRUB manual}).
+The output terminals used for the bootloader boot menu, as a list of
+symbols.  GRUB accepts the values: @code{console}, @code{serial},
+@code{serial_@{0-3@}}, @code{gfxterm}, @code{vga_text},
+@code{mda_text}, @code{morse}, and @code{pkmodem}.  This field
+corresponds to the GRUB variable GRUB_TERMINAL_OUTPUT (@pxref{Simple
+configuration,,, grub,GNU GRUB manual}).
 
 @item @code{terminal-inputs} (default: @code{'()})
-The input terminals used for the GRUB boot menu, as a list of symbols.
-The default is the native platform terminal as determined by GRUB at
-run-time.  These values are accepted: @code{console}, @code{serial},
-@code{serial_@{0-3@}}, @code{at_keyboard}, and @code{usb_keyboard}.
-This field corresponds to the GRUB variable GRUB_TERMINAL_INPUT
-(@pxref{Simple configuration,,, grub,GNU GRUB manual}).
+The input terminals used for the bootloader boot menu, as a list of
+symbols.  For GRUB, the default is the native platform terminal as
+determined at run-time.  GRUB accepts the values: @code{console},
+@code{serial}, @code{serial_@{0-3@}}, @code{at_keyboard}, and
+@code{usb_keyboard}.  This field corresponds to the GRUB variable
+GRUB_TERMINAL_INPUT (@pxref{Simple configuration,,, grub,GNU GRUB
+manual}).
 
 @item @code{serial-unit} (default: @code{#f})
-The serial unit used by GRUB, as an integer from 0 to 3.  The default
-value is chosen by GRUB at run-time; currently GRUB chooses 0, which
+The serial unit used by the bootloader, as an integer from 0 to 3.
+For GRUB it is choosen at run-time; currently GRUB chooses 0, which
 corresponds to COM1 (@pxref{Serial terminal,,, grub,GNU GRUB manual}).
 
 @item @code{serial-speed} (default: @code{#f})
-The speed of the serial interface, as an integer.  The default value is
-chosen by GRUB at run-time; currently GRUB chooses 9600@tie{}bps
-(@pxref{Serial terminal,,, grub,GNU GRUB manual}).
+The speed of the serial interface, as an integer.  For GRUB, the
+default value is chosen at run-time; currently GRUB chooses
+9600@tie{}bps (@pxref{Serial terminal,,, grub,GNU GRUB manual}).
 @end table
 
 @end deftp
@@ -15768,7 +15781,7 @@ along these lines:
 Details below.
 
 @deftp {Data Type} menu-entry
-The type of an entry in the GRUB boot menu.
+The type of an entry in the bootloader menu.
 
 @table @asis
 
@@ -15782,9 +15795,9 @@ The Linux kernel image to boot, for example:
 (file-append linux-libre "/bzImage")
 @end example
 
-It is also possible to specify a device explicitly in the file path
-using GRUB's device naming convention (@pxref{Naming convention,,, grub,
-GNU GRUB manual}), for example:
+For GRUB, It is also possible to specify a device explicitly in the
+file path using GRUB's device naming convention (@pxref{Naming
+convention,,, grub, GNU GRUB manual}), for example:
 
 @example
 "(hd0,msdos1)/boot/vmlinuz"
@@ -15800,16 +15813,15 @@ The list of extra Linux kernel command-line arguments---e.g.,
 @item @code{initrd}
 A G-Expression or string denoting the file name of the initial RAM disk
 to use (@pxref{G-Expressions}).
-
 @item @code{device} (default: @code{#f})
-The device where the kernel and initrd are to be found---i.e., the GRUB
+The device where the kernel and initrd are to be found---i.e., for GRUB,
 @dfn{root} for this menu entry (@pxref{root,,, grub, GNU GRUB manual}).
 
 This may be a file system label (a string), a file system UUID (a
-bytevector, @pxref{File Systems}), or @code{#f}, in which case GRUB will
-search the device containing the file specified by the @code{linux}
-field (@pxref{search,,, grub, GNU GRUB manual}).  It must @emph{not} be
-an OS device name such as @file{/dev/sda1}.
+bytevector, @pxref{File Systems}), or @code{#f}, in which case
+the bootloader will search the device containing the file specified by
+the @code{linux} field (@pxref{search,,, grub, GNU GRUB manual}).  It
+must @emph{not} be an OS device name such as @file{/dev/sda1}.
 
 @item @code{device-mount-point} (default: @code{"/"})
 The mount point of the above device on the system.  You probably do not
@@ -15821,12 +15833,16 @@ on a separate partition.
 @end deftp
 
 @c FIXME: Write documentation once it's stable.
-Themes are created using the @code{grub-theme} form, which is not
-documented yet.
+Fow now only GRUB has theme support. GRUB Themes are created using
+the @code{grub-theme} form, which is not documented yet.
 
 @defvr {Scheme Variable} %default-theme
-This is the default GRUB theme used by the operating system, with a
-fancy background image displaying the GNU and Guix logos.
+This is the default GRUB theme used by the operating system if no
+@code{theme} field is specified in @code{bootloader-configuration}
+record.
+
+It comes with a fancy background image displaying the GNU and Guix
+logos.
 @end defvr
 
 
@@ -15866,9 +15882,9 @@ list-generations}).  If that generation already exists, it will be
 overwritten.  This behavior mirrors that of @command{guix package}
 (@pxref{Invoking guix package}).
 
-It also adds a GRUB menu entry for the new OS configuration, and moves
-entries for older configurations to a submenu---unless
-@option{--no-bootloader} is passed.
+It also adds a bootloader menu entry for the new OS configuration,
+---unless @option{--no-bootloader} is passed.  For GRUB, it moves
+entries for older configurations to a submenu.
 
 @quotation Note
 @c The paragraph below refers to the problem discussed at
@@ -15882,11 +15898,12 @@ once @command{reconfigure} has completed.
 @item switch-generation
 @cindex generations
 Switch to an existing system generation.  This action atomically
-switches the system profile to the specified system generation.  It also
-rearranges the system's existing GRUB menu entries.  It makes the menu
-entry for the specified system generation the default, and it moves the
-entries for the other generations to a submenu.  The next time the
-system boots, it will use the specified system generation.
+switches the system profile to the specified system generation.  It
+also rearranges the system's existing bootloader menu entries.  It
+makes the menu entry for the specified system generation the default,
+and it moves the entries for the other generations to a submenu.  The
+next time the system boots, it will use the specified system
+generation.
 
 The target generation can be specified explicitly by its generation
 number.  For example, the following invocation would switch to system
@@ -15908,11 +15925,11 @@ guix system switch-generation -- -1
 @end example
 
 Currently, the effect of invoking this action is @emph{only} to switch
-the system profile to an existing generation and rearrange the GRUB menu
-entries.  To actually start using the target system generation, you must
-reboot after running this action.  In the future, it will be updated to
-do the same things as @command{reconfigure}, like activating and
-deactivating services.
+the system profile to an existing generation and rearrange the
+bootloader menu entries.  To actually start using the target system
+generation, you must reboot after running this action.  In the future,
+it will be updated to do the same things as @command{reconfigure},
+like activating and deactivating services.
 
 This action will fail if the specified generation does not exist.
 
@@ -15947,8 +15964,9 @@ files, packages, and so on.  It also creates other essential files
 needed for the system to operate correctly---e.g., the @file{/etc},
 @file{/var}, and @file{/run} directories, and the @file{/bin/sh} file.
 
-This command also installs GRUB on the device specified in
-@file{my-os-config}, unless the @option{--no-bootloader} option was passed.
+This command also installs bootloader on the device specified in
+@file{my-os-config}, unless the @option{--no-bootloader} option was
+passed.
 
 @item vm
 @cindex virtual machine
@@ -16088,7 +16106,7 @@ build users of the daemon (@pxref{Build Environment Setup}).
 Once you have built, configured, re-configured, and re-re-configured
 your GuixSD installation, you may find it useful to list the operating
 system generations available on disk---and that you can choose from the
-GRUB boot menu:
+bootloader boot menu:
 
 @table @code
 
-- 
2.13.0

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Danny Milosavljevic]

> +Note that all fields of @code{bootloader-configuration} are not
> +necessarily handled by all GuixSD supported bootloaders.

Sounds weird to me.

How about "Note that not all fields of ... are necessarily handled by every GuixSD-supported bootloader" ?

Otherwise LGTM!

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Danny Milosavljevic]

Hi Mathieu,

On Wed, 31 May 2017 09:23:27 +0200
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> +(define-record-type* <menu-entry>
...
> +  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp

For another future patch:  Hmm, should we make this optional?  I didn't have an initrd for many years.

> --- a/gnu/bootloader/extlinux.scm
> +++ b/gnu/bootloader/extlinux.scm
> @@ -37,7 +37,8 @@
>  corresponding to old generations of the system."
>  
>    (define all-entries
> -    (append entries (bootloader-configuration-menu-entries config)))
> +    (append entries (map menu-entry->boot-parameters
> +                         (bootloader-configuration-menu-entries config))))

Since we have menu-entry as a public datatype now, should we maybe use menu-entries for all the bootloader stuff ?  I think this would be easier to maintain because boot-parameters is a serialized format we can't easily change (because it's stored into a "parameters" file per generation, and generations can't ever be deleted).

In that case maybe it could rather be boot-parameters->menu-entry for the other (i.e. the GuixSD) entries instead of this.

> +  (define (boot-parameters->gexp params)

Maybe rather menu-entry->gexp and take a menu-entry ?

> +(define (menu-entry->boot-parameters menu-entry)

Then we'd have menu-entry->boot-parameters *and* boot-parameters->menu-entry which is usually a dead giveaway that we are doing something strange.  It would make it either a 1:1 map or lose data on the roundtrip, both of which are weird.

That's why I think if we have public <menu-entry> records anyway now, let's use them for the bootloader stuff throughout.

WDYT?

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

Hi Danny,

> For another future patch:  Hmm, should we make this optional?  I didn't have an initrd for many years.

Well I tried to run GuixSD without initrd and it's not possible
yet. Besides mounting root partition, it's also used to start the
initial guile script (/run/current-system/boot).

However, that's something I'd like to see :)

>
>> --- a/gnu/bootloader/extlinux.scm

> That's why I think if we have public <menu-entry> records anyway now, let's use them for the bootloader stuff throughout.

You're right there's something fishy here. But, if we want to remove the
notion of <boot-parameters> from (gnu bootloader ...), that would mean
that callers of "configuration-file-generator" will have to adapt their
API and that's a more consequent rework.

Ludo, any thoughts ?

Mathieu

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Danny Milosavljevic]

Hi Mathieu,

>Well I tried to run GuixSD without initrd and it's not possible yet.

People apparently start other Linux distributions with it :)

>a more consequent rework.

Uuuh another person hit the boot-parameters usability problem.  Let's get this patchset in and rework it later.

How's the error reporting?  If a user still has boot-parameters in his bootloader configuration menu-entries, will "guix system reconfigure" fail *before* he reboots?  If so, does the error message hint on how to fix it?

LGTM as is.  The user interface is now the same as it had been before (in 0.13.0) - so it's an improvement.

I just checked:  The 0.13.0 release is safe.  Phiew.

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Ludovic Courtès]

Hello,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> For another future patch:  Hmm, should we make this optional?  I didn't have an initrd for many years.
>
> Well I tried to run GuixSD without initrd and it's not possible
> yet. Besides mounting root partition, it's also used to start the
> initial guile script (/run/current-system/boot).
>
> However, that's something I'd like to see :)

I think it’s hard to achieve in general, unless you build the relevant
disk and file system drivers directly inside your kernel.  (The whole
point of the initrd is that you can keep a small kernel build and then
populate the initrd with the modules that are needed to mount the root
file system.)

(I’ll comment on the other issues separately!)

Ludo’.

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

Hi !

> People apparently start other Linux distributions with it :)

Yes because they use initrd only to mount root partition, then kernel is
starting /sbin/init provided by systemd or other init mechanism.

For people who's custom kernel is able to access root partition without
loading any module, maybe we could provide a kernel argument init=<path
of the boot script launching shepherd>.

Before GuixSD I didn't use an initrd to boot fastly. On GuixSD, because
shepherd start is quite slow (unparallelized ?) compared to systemd, the
few ms spent in initrd execution seems unsignificant.

But maybe there are other advantages not to run an initrd.

> How's the error reporting?  If a user still has boot-parameters in his bootloader configuration menu-entries, will "guix system reconfigure" fail *before* he reboots?  If so, does the error message hint on how to fix it?

Yes it will fail, some users have sadly already experimented this error.

> LGTM as is.  The user interface is now the same as it had been before (in 0.13.0) - so it's an improvement.
>
> I just checked:  The 0.13.0 release is safe.  Phiew.

Ok, let's wait for Ludo's approval then :)

Thanks for reviewing Danny,

Mathieu

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Marius Bakke]

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

Mathieu Othacehe <m.othacehe@gmail.com> writes:

> But maybe there are other advantages not to run an initrd.

CONFIG_MODULES=n reduces kernel attack surface significantly :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> * gnu/bootloader.scm (<menu-entry>): New variable. Export associated getters,
> This record is extracted from grub module.
> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use
>   menu-entry->boot-parameters to convert menu-entry records to
>   boot-parameters.
> * gnu/bootloader/grub.scm (<menu-entry>): Remove.
> (boot-parameters->menu-entry): Remove.
> (grub-configuration-file): Use boot-parameters to create configuration
> entries.
> * gnu/system.scm (menu-entry->boot-parameters): New exported procedure.

Overall LGTM.  Some comments and questions:

> +(define-record-type* <menu-entry>
> +  menu-entry make-menu-entry
> +  menu-entry?
> +  (label           menu-entry-label)
> +  (device          menu-entry-device       ; file system uuid, label, or #f
> +                   (default #f))
> +  (device-mount-point menu-entry-device-mount-point
> +                      (default "/"))
> +  (linux           menu-entry-linux)
> +  (linux-arguments menu-entry-linux-arguments
> +                   (default '()))          ; list of string-valued gexps
> +  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp

Do we still need ‘device-mount-point’ now?  For the dual-boot use case,
I don’t see how this would be used.

> +(define (menu-entry->boot-parameters menu-entry)
> +  "Convert a <menu-entry> instance to a corresponding <boot-parameters>."
> +  (boot-parameters
> +   (label (menu-entry-label menu-entry))
> +   (root-device #f)
> +   (boot-name 'custom)
> +   (store-device (menu-entry-device menu-entry))
> +   (store-mount-point (menu-entry-device-mount-point menu-entry))
> +   (kernel (menu-entry-linux menu-entry))
> +   (kernel-arguments (menu-entry-linux-arguments menu-entry))
> +   (initrd (menu-entry-initrd menu-entry))))

It’s weird to set ‘store-device’ and ‘store-mount-point’ here since
there’s no store (at least when defining a menu entry for another distro
or OS).  Should we set them to #f?

BTW, this is unrelated to this patch series, but I think ‘boot-name’
should be renamed to ‘bootloader-name’ since that’s what it is.

Thank you for working on this!

Ludo’.

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Ludovic Courtès]

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> * doc/guix.texi (GRUB configuration): Rename to "Bootloader
>   configuration".
>   Adapt occurences of "GRUB" in other sections.

Awesome, thanks for reviewing and updating all the doc!

Some minor comments/suggestions:

> -@node GRUB Configuration
> -@subsection GRUB Configuration
> +@node Bootloader Configuration
> +@subsection Bootloader Configuration
>  
> -@cindex GRUB
> +@cindex Bootloader

Lowercase please.

> +The operating system supports multiple bootloaders. The bootloader is
> +configured using @code{bootloader-configuration} declaration. All the
> +fields of this structure are bootloader agnostic except for one field,
> +@code{bootloader} that indicates the bootloader to be configured and
> +installed.

Nitpick: please make sure to leave two spaces after an end-of-sentence
period.

>  @c FIXME: Write documentation once it's stable.
> -Themes are created using the @code{grub-theme} form, which is not
> -documented yet.
> +Fow now only GRUB has theme support. GRUB Themes are created using

s/Themes/themes/

> +It also adds a bootloader menu entry for the new OS configuration,
> +---unless @option{--no-bootloader} is passed.  For GRUB, it moves
> +entries for older configurations to a submenu.

s/to a submenu/to a submenu, allowing you to choose an older system
generation at boot time should you need it/

What happens with other bootloaders?  Do we get older boot entries?  It
might be worth mentioning.

>  @item switch-generation
>  @cindex generations
>  Switch to an existing system generation.  This action atomically
> -switches the system profile to the specified system generation.  It also
> -rearranges the system's existing GRUB menu entries.  It makes the menu
> -entry for the specified system generation the default, and it moves the
> -entries for the other generations to a submenu.  The next time the
> -system boots, it will use the specified system generation.
> +switches the system profile to the specified system generation.  It
> +also rearranges the system's existing bootloader menu entries.  It
> +makes the menu entry for the specified system generation the default,
> +and it moves the entries for the other generations to a submenu.  The
> +next time the system boots, it will use the specified system
> +generation.

What happens to the bootloader itself?  Does it change the bootloader to
the one that was chosen back then?

Thank you!

Ludo’.

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> +Note that all fields of @code{bootloader-configuration} are not
>> +necessarily handled by all GuixSD supported bootloaders.
>
> Sounds weird to me.
>
> How about "Note that not all fields of ... are necessarily handled by every GuixSD-supported bootloader" ?

Or: “Some of the bootloaders do not honor every field of
@code{bootloader-configuration}.  For instance, the extlinux bootloader
does not support themes and thus ignores the @code{theme} field.”  ?

Ludo’.

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Danny Milosavljevic]

Hi Ludo,

On Mon, 05 Jun 2017 12:36:28 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> What happens with other bootloaders?  Do we get older boot entries?

Yes, but U-Boot has no support for submenus, only one menu [1].  Extlinux-the-format technically does support submenus [2].

> >  @item switch-generation

> What happens to the bootloader itself?  Does it change the bootloader to
> the one that was chosen back then?

No.  We had been thinking about it but it's unsafe to do that.

So instead switch-generation will always reuse the bootloader that was used in the current generation.

switch-generation has the same effect as manually selecting another menu entry from the boot menu on bootup would have had - it just additionally defaults to that entry.

On the other hand, when you run "guix system reconfigure" or "guix system init":  There, it will install and use the (newly) specified one.

[1] See also <https://github.com/u-boot/u-boot/blob/master/cmd/bootmenu.c>.
[2] See also <http://www.syslinux.org/wiki/index.php?title=Menu#MENU_BEGIN>.

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

Hi Ludo,

> Do we still need ‘device-mount-point’ now?  For the dual-boot use case,
> I don’t see how this would be used.

Nope, you're right it's not needed in <menu-entry>.

>> +   (initrd (menu-entry-initrd menu-entry))))
>
> It’s weird to set ‘store-device’ and ‘store-mount-point’ here since
> there’s no store (at least when defining a menu entry for another distro
> or OS).  Should we set them to #f?

Sound ok !

> BTW, this is unrelated to this patch series, but I think ‘boot-name’
> should be renamed to ‘bootloader-name’ since that’s what it is.

Ok.

> Thank you for working on this!

Thanks for reviewing :)

Mathieu

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Mathieu Othacehe]

> What happens with other bootloaders?  Do we get older boot entries?  It
> might be worth mentioning.

On extlinux we also get older boot entries but not in a submenu. I plan
to add submenu support in a new serie.

I'll mention that this is true for all supported bootloaders when this
will be done.

> What happens to the bootloader itself?  Does it change the bootloader to
> the one that was chosen back then?

Nope, as Danny stated, the bootloader in not reinstalled, but the conf
file is updated. I'll add this info to the doc.

Thanks,

Mathieu

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Mon, 05 Jun 2017 12:36:28 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> What happens with other bootloaders?  Do we get older boot entries?
>
> Yes, but U-Boot has no support for submenus, only one menu [1].  Extlinux-the-format technically does support submenus [2].

OK.

>> >  @item switch-generation
>
>> What happens to the bootloader itself?  Does it change the bootloader to
>> the one that was chosen back then?
>
> No.  We had been thinking about it but it's unsafe to do that.
>
> So instead switch-generation will always reuse the bootloader that was used in the current generation.
>
> switch-generation has the same effect as manually selecting another menu entry from the boot menu on bootup would have had - it just additionally defaults to that entry.
>
> On the other hand, when you run "guix system reconfigure" or "guix system init":  There, it will install and use the (newly) specified one.

OK, got it, thanks for clarifying!

I think it would make sense to be explicit about this in the manual.

Ludo’.

bug#27007: [PATCH v2 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Mathieu Othacehe]

* gnu/bootloader.scm (<menu-entry>): New variable. Export associated getters,
This record is extracted from grub module.
* gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use
  menu-entry->boot-parameters to convert menu-entry records to
  boot-parameters.
* gnu/bootloader/grub.scm (<menu-entry>): Remove.
(boot-parameters->menu-entry): Remove.
(grub-configuration-file): Use boot-parameters to create configuration
entries.
* gnu/system.scm (menu-entry->boot-parameters): New exported procedure.
---
 gnu/bootloader.scm          | 26 ++++++++++++++-
 gnu/bootloader/extlinux.scm |  3 +-
 gnu/bootloader/grub.scm     | 77 ++++++++++++++++++---------------------------
 gnu/system.scm              | 14 +++++++++
 4 files changed, 71 insertions(+), 49 deletions(-)

diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm
index 4e77974d3..d5fcf30f0 100644
--- a/gnu/bootloader.scm
+++ b/gnu/bootloader.scm
@@ -23,7 +23,15 @@
   #:use-module (guix records)
   #:use-module (guix ui)
   #:use-module (srfi srfi-1)
-  #:export (bootloader
+  #:export (menu-entry
+            menu-entry?
+            menu-entry-label
+            menu-entry-device
+            menu-entry-linux
+            menu-entry-linux-arguments
+            menu-entry-initrd
+
+            bootloader
             bootloader?
             bootloader-name
             bootloader-package
@@ -50,6 +58,22 @@
 
 \f
 ;;;
+;;; Menu-entry record.
+;;;
+
+(define-record-type* <menu-entry>
+  menu-entry make-menu-entry
+  menu-entry?
+  (label           menu-entry-label)
+  (device          menu-entry-device       ; file system uuid, label, or #f
+                   (default #f))
+  (linux           menu-entry-linux)
+  (linux-arguments menu-entry-linux-arguments
+                   (default '()))          ; list of string-valued gexps
+  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp
+
+\f
+;;;
 ;;; Bootloader record.
 ;;;
 
diff --git a/gnu/bootloader/extlinux.scm b/gnu/bootloader/extlinux.scm
index 67b8815d4..0a1263aed 100644
--- a/gnu/bootloader/extlinux.scm
+++ b/gnu/bootloader/extlinux.scm
@@ -37,7 +37,8 @@
 corresponding to old generations of the system."
 
   (define all-entries
-    (append entries (bootloader-configuration-menu-entries config)))
+    (append entries (map menu-entry->boot-parameters
+                         (bootloader-configuration-menu-entries config))))
 
   (define (boot-parameters->gexp params)
     (let ((label (boot-parameters-label params))
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 49616b716..f1cc3324d 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -66,12 +66,15 @@
 (define (strip-mount-point mount-point file)
   "Strip MOUNT-POINT from FILE, which is a gexp or other lowerable object
 denoting a file name."
-  (if (string=? mount-point "/")
-      file
-      #~(let ((file #$file))
-          (if (string-prefix? #$mount-point file)
-              (substring #$file #$(string-length mount-point))
-              file))))
+  (match mount-point
+    ((? string? mount-point)
+     (if (string=? mount-point "/")
+         file
+         #~(let ((file #$file))
+             (if (string-prefix? #$mount-point file)
+                 (substring #$file #$(string-length mount-point))
+                 file))))
+    (#f file)))
 
 (define-record-type* <grub-image>
   grub-image make-grub-image
@@ -103,19 +106,6 @@ denoting a file name."
    (color-highlight '((fg . yellow) (bg . black)))
    (color-normal    '((fg . light-gray) (bg . black))))) ;XXX: #x303030
 
-(define-record-type* <menu-entry>
-  menu-entry make-menu-entry
-  menu-entry?
-  (label           menu-entry-label)
-  (device          menu-entry-device       ; file system uuid, label, or #f
-                   (default #f))
-  (device-mount-point menu-entry-device-mount-point
-                      (default "/"))
-  (linux           menu-entry-linux)
-  (linux-arguments menu-entry-linux-arguments
-                   (default '()))          ; list of string-valued gexps
-  (initrd          menu-entry-initrd))     ; file name of the initrd as a gexp
-
 \f
 ;;;
 ;;; Background image & themes.
@@ -312,16 +302,6 @@ code."
         (#f
          #~(format #f "search --file --set ~a" #$file)))))
 
-(define (boot-parameters->menu-entry conf)
-  "Convert a <boot-parameters> instance to a corresponding <menu-entry>."
-  (menu-entry
-   (label (boot-parameters-label conf))
-   (device (boot-parameters-store-device conf))
-   (device-mount-point (boot-parameters-store-mount-point conf))
-   (linux (boot-parameters-kernel conf))
-   (linux-arguments (boot-parameters-kernel-arguments conf))
-   (initrd (boot-parameters-initrd conf))))
-
 (define* (grub-configuration-file config entries
                                   #:key
                                   (system (%current-system))
@@ -331,33 +311,36 @@ code."
 STORE-FS, a <file-system> object.  OLD-ENTRIES is taken to be a list of menu
 entries corresponding to old generations of the system."
   (define all-entries
-    (map boot-parameters->menu-entry
-         (append entries
-                 (bootloader-configuration-menu-entries config))))
-
-  (define entry->gexp
-    (match-lambda
-     (($ <menu-entry> label device device-mount-point
-                      linux arguments initrd)
+    (append entries (map menu-entry->boot-parameters
+                         (bootloader-configuration-menu-entries config))))
+
+  (define (boot-parameters->gexp params)
+    (let ((device (boot-parameters-store-device params))
+          (device-mount-point (boot-parameters-store-mount-point params))
+          (label (boot-parameters-label params))
+          (kernel (boot-parameters-kernel params))
+          (arguments (boot-parameters-kernel-arguments params))
+          (initrd (boot-parameters-initrd params)))
       ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
-      ;; Use the right file names for LINUX and INITRD in case
+      ;; Use the right file names for KERNEL and INITRD in case
       ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
       ;; separate partition.
-      (let ((linux  (strip-mount-point device-mount-point linux))
-            (initrd (strip-mount-point device-mount-point initrd)))
+      (let ((kernel  (strip-mount-point device-mount-point kernel))
+            (initrd  (strip-mount-point device-mount-point initrd)))
         #~(format port "menuentry ~s {
   ~a
   linux ~a ~a
   initrd ~a
 }~%"
                   #$label
-                  #$(grub-root-search device linux)
-                  #$linux (string-join (list #$@arguments))
-                  #$initrd)))))
+                  #$(grub-root-search device kernel)
+                  #$kernel (string-join (list #$@arguments))
+                  #$initrd))))
 
   (mlet %store-monad ((sugar (eye-candy config
-                                        (menu-entry-device (first all-entries))
-                                        (menu-entry-device-mount-point
+                                        (boot-parameters-store-device
+                                         (first all-entries))
+                                        (boot-parameters-store-mount-point
                                          (first all-entries))
                                         #:system system
                                         #:port #~port)))
@@ -374,12 +357,12 @@ set default=~a
 set timeout=~a~%"
                     #$(bootloader-configuration-default-entry config)
                     #$(bootloader-configuration-timeout config))
-            #$@(map entry->gexp all-entries)
+            #$@(map boot-parameters->gexp all-entries)
 
             #$@(if (pair? old-entries)
                    #~((format port "
 submenu \"GNU system, old configurations...\" {~%")
-                      #$@(map entry->gexp (map boot-parameters->menu-entry old-entries))
+                      #$@(map boot-parameters->gexp old-entries)
                       (format port "}~%"))
                    #~()))))
 
diff --git a/gnu/system.scm b/gnu/system.scm
index 0076f2fcb..674c6f85b 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -112,6 +112,7 @@
             boot-parameters-initrd
             read-boot-parameters
             read-boot-parameters-file
+            menu-entry->boot-parameters
 
             local-host-aliases
             %setuid-programs
@@ -299,6 +300,19 @@ The object has its kernel-arguments extended in order to make it bootable."
                                                      system
                                                      root-device)))
       #f)))
+
+(define (menu-entry->boot-parameters menu-entry)
+  "Convert a <menu-entry> instance to a corresponding <boot-parameters>."
+  (boot-parameters
+   (label (menu-entry-label menu-entry))
+   (root-device #f)
+   (boot-name 'custom)
+   (store-device #f)
+   (store-mount-point #f)
+   (kernel (menu-entry-linux menu-entry))
+   (kernel-arguments (menu-entry-linux-arguments menu-entry))
+   (initrd (menu-entry-initrd menu-entry))))
+
 \f
 ;;;
 ;;; Services.
-- 
2.13.0

bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.

[Mathieu Othacehe]

* doc/guix.texi (GRUB configuration): Rename to "Bootloader
  configuration".
  Remove device-mount-point field from menu-entry description.
  Adapt occurences of "GRUB" in other sections.
---
 doc/guix.texi | 177 ++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 98 insertions(+), 79 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index f69c84dea..00bf24d3f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -199,7 +199,7 @@ System Configuration
 * X.509 Certificates::          Authenticating HTTPS servers.
 * Name Service Switch::         Configuring libc's name service switch.
 * Initial RAM Disk::            Linux-Libre bootstrapping.
-* GRUB Configuration::          Configuring the boot loader.
+* Bootloader Configuration::    Configuring the boot loader.
 * Invoking guix system::        Instantiating a system configuration.
 * Running GuixSD in a VM::      How to run GuixSD in a virtual machine.
 * Defining Services::           Adding new service definitions.
@@ -7797,7 +7797,7 @@ instance to support new system services.
 * X.509 Certificates::          Authenticating HTTPS servers.
 * Name Service Switch::         Configuring libc's name service switch.
 * Initial RAM Disk::            Linux-Libre bootstrapping.
-* GRUB Configuration::          Configuring the boot loader.
+* Bootloader Configuration::    Configuring the boot loader.
 * Invoking guix system::        Instantiating a system configuration.
 * Running GuixSD in a VM::      How to run GuixSD in a virtual machine.
 * Defining Services::           Adding new service definitions.
@@ -7980,7 +7980,7 @@ system, should you ever need to.
 Speaking of roll-back, each time you run @command{guix system
 reconfigure}, a new @dfn{generation} of the system is created---without
 modifying or deleting previous generations.  Old system generations get
-an entry in the GRUB boot menu, allowing you to boot them in case
+an entry in the bootloader boot menu, allowing you to boot them in case
 something went wrong with the latest generation.  Reassuring, no?  The
 @command{guix system list-generations} command lists the system
 generations available on disk.  It is also possible to roll back the
@@ -8036,7 +8036,7 @@ List of strings or gexps representing additional arguments to pass on
 the command-line of the kernel---e.g., @code{("console=ttyS0")}.
 
 @item @code{bootloader}
-The system bootloader configuration object.  @xref{GRUB Configuration}.
+The system bootloader configuration object.  @xref{Bootloader Configuration}.
 
 @item @code{initrd} (default: @code{base-initrd})
 @cindex initrd
@@ -15711,32 +15711,52 @@ upon booting.  All the derivations referenced by @var{exp} are
 automatically copied to the initrd.
 @end deffn
 
-@node GRUB Configuration
-@subsection GRUB Configuration
+@node Bootloader Configuration
+@subsection Bootloader Configuration
 
-@cindex GRUB
+@cindex bootloader
 @cindex boot loader
 
-The operating system uses GNU@tie{}GRUB as its boot loader
-(@pxref{Overview, overview of GRUB,, grub, GNU GRUB Manual}).  It is
-configured using a @code{grub-configuration} declaration.  This data type
-is exported by the @code{(gnu system grub)} module and described below.
+The operating system supports multiple bootloaders.  The bootloader is
+configured using @code{bootloader-configuration} declaration.  All the
+fields of this structure are bootloader agnostic except for one field,
+@code{bootloader} that indicates the bootloader to be configured and
+installed.
 
-@deftp {Data Type} grub-configuration
-The type of a GRUB configuration declaration.
+Some of the bootloaders do not honor every field of
+@code{bootloader-configuration}.  For instance, the extlinux
+bootloader does not support themes and thus ignores the @code{theme}
+field.
+
+@deftp {Data Type} bootloader-configuration
+The type of a bootloader configuration declaration.
 
 @table @asis
 
+@item @code{bootloader}
+@cindex EFI, bootloader
+@cindex UEFI, bootloader
+@cindex BIOS, bootloader
+The bootloader to use, as a @code{bootloader} object. For now
+@code{grub-bootloader}, @code{grub-efi-bootloader} and
+@code{extlinux-bootloader} are supported.  @code{grub-efi-bootloader},
+allows to boot on modern systems using the @dfn{Unified Extensible
+Firmware Interface} (UEFI).
+
+Available bootloaders are described in @code{(gnu bootloader @dots{})}
+modules.
+
 @item @code{device}
 This is a string denoting the boot device.  It must be a device name
-understood by the @command{grub-install} command, such as
-@code{/dev/sda} or @code{(hd0)} (@pxref{Invoking grub-install,,, grub,
+understood by the bootloader @command{installer} command, such as
+@code{/dev/sda} or @code{(hd0)} (for GRUB, @pxref{Invoking grub-install,,, grub,
 GNU GRUB Manual}).
 
 @item @code{menu-entries} (default: @code{()})
 A possibly empty list of @code{menu-entry} objects (see below), denoting
-entries to appear in the GRUB boot menu, in addition to the current
+entries to appear in the bootloader menu, in addition to the current
 system entry and the entry pointing to previous system generations.
+generations.
 
 @item @code{default-entry} (default: @code{0})
 The index of the default boot menu entry.  Index 0 is for the entry of the
@@ -15746,42 +15766,37 @@ current system.
 The number of seconds to wait for keyboard input before booting.  Set to
 0 to boot immediately, and to -1 to wait indefinitely.
 
-@item @code{theme} (default: @var{%default-theme})
-The @code{grub-theme} object describing the theme to use.
-
-@item @code{grub} (default: @code{grub})
-@cindex EFI, bootloader
-@cindex UEFI, bootloader
-@cindex BIOS, bootloader
-The GRUB package to use.  Currently either @code{grub}, for ``legacy''
-x86 BIOS systems, or @code{grub-efi}, for modern systems using the
-@dfn{Unified Extensible Firmware Interface} (UEFI).
+@item @code{theme} (default: @var{#f})
+The bootloader theme object describing the theme to use.  If no theme
+is provided, some bootloaders might use a default theme, that's true
+for GRUB.
 
 @item @code{terminal-outputs} (default: @code{'gfxterm})
-The output terminals used for the GRUB boot menu, as a list of symbols.
-These values are accepted: @code{console}, @code{serial},
-@code{serial_@{0-3@}}, @code{gfxterm}, @code{vga_text}, @code{mda_text},
-@code{morse}, and @code{pkmodem}.  This field corresponds to the GRUB
-variable GRUB_TERMINAL_OUTPUT (@pxref{Simple configuration,,, grub,GNU
-GRUB manual}).
+The output terminals used for the bootloader boot menu, as a list of
+symbols.  GRUB accepts the values: @code{console}, @code{serial},
+@code{serial_@{0-3@}}, @code{gfxterm}, @code{vga_text},
+@code{mda_text}, @code{morse}, and @code{pkmodem}.  This field
+corresponds to the GRUB variable GRUB_TERMINAL_OUTPUT (@pxref{Simple
+configuration,,, grub,GNU GRUB manual}).
 
 @item @code{terminal-inputs} (default: @code{'()})
-The input terminals used for the GRUB boot menu, as a list of symbols.
-The default is the native platform terminal as determined by GRUB at
-run-time.  These values are accepted: @code{console}, @code{serial},
-@code{serial_@{0-3@}}, @code{at_keyboard}, and @code{usb_keyboard}.
-This field corresponds to the GRUB variable GRUB_TERMINAL_INPUT
-(@pxref{Simple configuration,,, grub,GNU GRUB manual}).
+The input terminals used for the bootloader boot menu, as a list of
+symbols.  For GRUB, the default is the native platform terminal as
+determined at run-time.  GRUB accepts the values: @code{console},
+@code{serial}, @code{serial_@{0-3@}}, @code{at_keyboard}, and
+@code{usb_keyboard}.  This field corresponds to the GRUB variable
+GRUB_TERMINAL_INPUT (@pxref{Simple configuration,,, grub,GNU GRUB
+manual}).
 
 @item @code{serial-unit} (default: @code{#f})
-The serial unit used by GRUB, as an integer from 0 to 3.  The default
-value is chosen by GRUB at run-time; currently GRUB chooses 0, which
+The serial unit used by the bootloader, as an integer from 0 to 3.
+For GRUB it is choosen at run-time; currently GRUB chooses 0, which
 corresponds to COM1 (@pxref{Serial terminal,,, grub,GNU GRUB manual}).
 
 @item @code{serial-speed} (default: @code{#f})
-The speed of the serial interface, as an integer.  The default value is
-chosen by GRUB at run-time; currently GRUB chooses 9600@tie{}bps
-(@pxref{Serial terminal,,, grub,GNU GRUB manual}).
+The speed of the serial interface, as an integer.  For GRUB, the
+default value is chosen at run-time; currently GRUB chooses
+9600@tie{}bps (@pxref{Serial terminal,,, grub,GNU GRUB manual}).
 @end table
 
 @end deftp
@@ -15805,7 +15820,7 @@ along these lines:
 Details below.
 
 @deftp {Data Type} menu-entry
-The type of an entry in the GRUB boot menu.
+The type of an entry in the bootloader menu.
 
 @table @asis
 
@@ -15819,9 +15834,9 @@ The Linux kernel image to boot, for example:
 (file-append linux-libre "/bzImage")
 @end example
 
-It is also possible to specify a device explicitly in the file path
-using GRUB's device naming convention (@pxref{Naming convention,,, grub,
-GNU GRUB manual}), for example:
+For GRUB, it is also possible to specify a device explicitly in the
+file path using GRUB's device naming convention (@pxref{Naming
+convention,,, grub, GNU GRUB manual}), for example:
 
 @example
 "(hd0,msdos1)/boot/vmlinuz"
@@ -15837,33 +15852,30 @@ The list of extra Linux kernel command-line arguments---e.g.,
 @item @code{initrd}
 A G-Expression or string denoting the file name of the initial RAM disk
 to use (@pxref{G-Expressions}).
-
 @item @code{device} (default: @code{#f})
-The device where the kernel and initrd are to be found---i.e., the GRUB
+The device where the kernel and initrd are to be found---i.e., for GRUB,
 @dfn{root} for this menu entry (@pxref{root,,, grub, GNU GRUB manual}).
 
 This may be a file system label (a string), a file system UUID (a
-bytevector, @pxref{File Systems}), or @code{#f}, in which case GRUB will
-search the device containing the file specified by the @code{linux}
-field (@pxref{search,,, grub, GNU GRUB manual}).  It must @emph{not} be
-an OS device name such as @file{/dev/sda1}.
-
-@item @code{device-mount-point} (default: @code{"/"})
-The mount point of the above device on the system.  You probably do not
-need to change the default value.  GuixSD uses it to strip the prefix of
-store file names for systems where @file{/gnu} or @file{/gnu/store} is
-on a separate partition.
+bytevector, @pxref{File Systems}), or @code{#f}, in which case
+the bootloader will search the device containing the file specified by
+the @code{linux} field (@pxref{search,,, grub, GNU GRUB manual}).  It
+must @emph{not} be an OS device name such as @file{/dev/sda1}.
 
 @end table
 @end deftp
 
 @c FIXME: Write documentation once it's stable.
-Themes are created using the @code{grub-theme} form, which is not
-documented yet.
+Fow now only GRUB has theme support. GRUB themes are created using
+the @code{grub-theme} form, which is not documented yet.
 
 @defvr {Scheme Variable} %default-theme
-This is the default GRUB theme used by the operating system, with a
-fancy background image displaying the GNU and Guix logos.
+This is the default GRUB theme used by the operating system if no
+@code{theme} field is specified in @code{bootloader-configuration}
+record.
+
+It comes with a fancy background image displaying the GNU and Guix
+logos.
 @end defvr
 
 
@@ -15903,9 +15915,10 @@ list-generations}).  If that generation already exists, it will be
 overwritten.  This behavior mirrors that of @command{guix package}
 (@pxref{Invoking guix package}).
 
-It also adds a GRUB menu entry for the new OS configuration, and moves
-entries for older configurations to a submenu---unless
-@option{--no-bootloader} is passed.
+It also adds a bootloader menu entry for the new OS configuration,
+---unless @option{--no-bootloader} is passed.  For GRUB, it moves
+entries for older configurations to a submenu, allowing you to choose
+an older system generation at boot time should you need it.
 
 @quotation Note
 @c The paragraph below refers to the problem discussed at
@@ -15919,11 +15932,16 @@ once @command{reconfigure} has completed.
 @item switch-generation
 @cindex generations
 Switch to an existing system generation.  This action atomically
-switches the system profile to the specified system generation.  It also
-rearranges the system's existing GRUB menu entries.  It makes the menu
-entry for the specified system generation the default, and it moves the
-entries for the other generations to a submenu.  The next time the
-system boots, it will use the specified system generation.
+switches the system profile to the specified system generation.  It
+also rearranges the system's existing bootloader menu entries.  It
+makes the menu entry for the specified system generation the default,
+and it moves the entries for the other generatiors to a submenu, if
+supported by the bootloader being used.  The next time the system
+boots, it will use the specified system generation.
+
+The bootloader itself is not being reinstalled when using this
+command.  Thus, the installed bootloader is used with an updated
+configuration file.
 
 The target generation can be specified explicitly by its generation
 number.  For example, the following invocation would switch to system
@@ -15945,11 +15963,11 @@ guix system switch-generation -- -1
 @end example
 
 Currently, the effect of invoking this action is @emph{only} to switch
-the system profile to an existing generation and rearrange the GRUB menu
-entries.  To actually start using the target system generation, you must
-reboot after running this action.  In the future, it will be updated to
-do the same things as @command{reconfigure}, like activating and
-deactivating services.
+the system profile to an existing generation and rearrange the
+bootloader menu entries.  To actually start using the target system
+generation, you must reboot after running this action.  In the future,
+it will be updated to do the same things as @command{reconfigure},
+like activating and deactivating services.
 
 This action will fail if the specified generation does not exist.
 
@@ -15984,8 +16002,9 @@ files, packages, and so on.  It also creates other essential files
 needed for the system to operate correctly---e.g., the @file{/etc},
 @file{/var}, and @file{/run} directories, and the @file{/bin/sh} file.
 
-This command also installs GRUB on the device specified in
-@file{my-os-config}, unless the @option{--no-bootloader} option was passed.
+This command also installs bootloader on the device specified in
+@file{my-os-config}, unless the @option{--no-bootloader} option was
+passed.
 
 @item vm
 @cindex virtual machine
@@ -16125,7 +16144,7 @@ build users of the daemon (@pxref{Build Environment Setup}).
 Once you have built, configured, re-configured, and re-re-configured
 your GuixSD installation, you may find it useful to list the operating
 system generations available on disk---and that you can choose from the
-GRUB boot menu:
+bootloader boot menu:
 
 @table @code
 
-- 
2.13.0

bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.

[Mathieu Othacehe]

Hi,

Just sent a v2 addressing your remarks !

Thanks,

Mathieu

> I think it would make sense to be explicit about this in the manual.
>
> Ludo’.

bug#27007: [PATCH v2 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> * gnu/bootloader.scm (<menu-entry>): New variable. Export associated getters,
> This record is extracted from grub module.
> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use
>   menu-entry->boot-parameters to convert menu-entry records to
>   boot-parameters.
> * gnu/bootloader/grub.scm (<menu-entry>): Remove.
> (boot-parameters->menu-entry): Remove.
> (grub-configuration-file): Use boot-parameters to create configuration
> entries.
> * gnu/system.scm (menu-entry->boot-parameters): New exported procedure.

LGTM!

Ludo’.

bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.

[Ludovic Courtès]

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> * doc/guix.texi (GRUB configuration): Rename to "Bootloader
>   configuration".
>   Remove device-mount-point field from menu-entry description.
>   Adapt occurences of "GRUB" in other sections.

LGTM.

In the future, I think it’ll be preferable to commit code/tests/doc
together.  That is, in the commit that changes the API from being
GRUB-specific to supporting multiple bootloaders, we include not only
the code but also the doc update.  This simplifies review, makes sure
each commit is self-contained, and ensure that users get consistent
documentation.

Thanks again!

Ludo’.

bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.

[Mathieu Othacehe]

> In the future, I think it’ll be preferable to commit code/tests/doc
> together.  That is, in the commit that changes the API from being
> GRUB-specific to supporting multiple bootloaders, we include not only
> the code but also the doc update.  This simplifies review, makes sure
> each commit is self-contained, and ensure that users get consistent
> documentation.

Yes I noticed this has confused some users, sorry for that :(.

I pushed the two commits.

Thanks,

Mathieu