bug#26339: [PATCH] doc: Adapt to multiple bootloader support.

[Danny Milosavljevic]

Hi Mathieu,

On Tue, 16 May 2017 15:03:06 +0200
Mathieu Othacehe <address@hidden> wrote:
> Here's the doc patch. While writting it, I noticed that using
> <boot-parameters> for <bootloader-configuration>'s menu-entry fields
> was maybe not a good idea.
> 
> <boot-parameters> has no default values and it might be hard to understand
> by final users. WDYT ?

From an understanding standpoint I don't think it's that bad.

What worries me more is that now AND BEFORE, you can't boot anything other than 
Linux, no bootsector chainloading or anything.

I'm not sure what the use case that "menu-entries" is trying to address is, 
then.  I mean both the current generation and previous generations are 
automatically there and you can't specify any menu-entries but Linux, so what 
are you gonna specify?  Also, <operating-system> already allows overriding 
kernel-arguments, too.

Luckily, Tomáš Čech just noticed that "menu-entries" changed, so presumably he 
uses it.  Will ask what use case he has...

> +(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

This here isn't so bad.

> address@hidden @code{root-device}
> +The root device identifier. It has to correspond exactly to the device
> +field of the <file-system> object representing the OS's root file
> +system, so it might be a device path like @code{"/dev/sda3"}.
> +
> address@hidden @code{boot-device}

Did you mean "boot-name" ?

> +The name of the bootloader used to boot this entry (@code{'grub} or
> address@hidden'syslinux} for instance).

This one is a strange implementation detail to expose for menu entries, though. 
 Maybe have operating-system-bootcfg magically complete it if it's unset?

Then add here "If in doubt, don't specify it.".

> address@hidden @code{store-device}
> +The device where the kernel and initrd are to be found---i.e., for GRUB
> address@hidden for this menu entry (@pxref{root,,, grub, GNU GRUB manual}).
> +
> +Depending on the bootloader, this may be a file system label (a
> +string), a file system UUID (a bytevector, @pxref{File Systems}), or
> address@hidden If set to @code{#f}, 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
> address@hidden/dev/sda1}.

Maybe default to #f in <boot-parameters> in gnu/system.scm ?

Then add here "If in doubt, don't specify it.".

> address@hidden @code{store-mount-point}
> +The mount point of the above device on the system.  You probably want
> +to set it to @code{"/"}.  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.

Maybe default to "/" in <boot-parameters? in gnu/system.scm ?

Then add here "If in doubt, don't specify it.".

That would make the amount of new fields the user has to specify to one, just 
"root-device".

That said, I'm wondering whether we should keep menu-entries at all (or if we 
do, maybe make it bootloader-specific like it was? At least then you can add 
entries that Guix doesn't use already).  Let's see what Tomáš says it's for :)