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

[Mathieu Othacehe]

Hi Danny,

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

My concern is about the new fields, that might be hard to understand.

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

Based on Tomáš answer, I guess menu-entries are used to boot on other
Linux distributions. "reconfigure" is not able to "see" those distributions by
himself, so the only way to add them to bootloader configuration is via
menu-entries.

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

Yes it's a mistake :)

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

Yes I totally agree. Maybe set it to 'unknown by default ?

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

Ok.

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

Ok.

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

Ok.

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

Yes seems better.

> 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 :)

I'll propose a new patch.

Thanks !

Mathieu