[bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.

[Danny Milosavljevic]

Hi Stefan,

On Sun, 24 May 2020 12:18:38 +0200
Stefan <address@hidden> wrote:

> But I’m not sure, if the field bootloader-name can be dropped then[after 
> adding bootloader-configuration-file to boot-parameters] from 
> <boot-parameters>. But if, then we could probably also drop the field name 
> from the <bootloader> record. 

We definitely can't drop it.  The name is required in order to know which
bootloader to restore when deleting system generations.  After all you could be
deleting the generation that switched from extlinux to grub.  How to boot then?

(see lookup-bootloader-by-name call site)

Since we are trying to have the bootloader to use part of the Guix system
configuration (for better or for worse), we have to be really careful to
pick the right bootloader and generate the configuration for the right
bootloader, otherwise the computer won't boot anymore *and* you couldn't
select the before-fuckup generation anymore either.

> Yes, it’s kind of possible to inherit from grub-efi-bootloader and overwrite
the (configuration-file) field. In a first step this seems to work. But when
e.g. deleting a system generation, in guix/scripts/system.scm
(reinstall-bootloader) there is this code:
>
>     ;; Use the detected bootloader with default configuration.
>     ;; It will be enough to allow the system to boot.
>     (bootloader-config (bootloader-configuration
>                         (bootloader bootloader))) 

>In <boot-parameters> it seems – but I’m not sure yet – that we only keep a 
>symbol name to figure out the path to the grub.cfg, although it is possible to 
>just put that path directly there instead. And using the symbol makes it hard 
>do get a configurable bootloader: A new bootloader has to be a variable, 
>tricks with macros come up. Also inheriting from a bootloader and overwriting 
>the configuration-file field – for whatever reason – is problematic: It seems 
>to work at the beginning, but only fails badly when removing a system 
>generation. It seems to have subtle bugs. It’s not usable like other parts in 
>guix. It’s not hackable. I’d really prefer to change this.

Yeah, well...  that is the only way we could think of to make sure it actually
boots in all cases, as it is right now.

(Though if the user had custom entries, that would nuke all of them--but
that's still better than not being able to boot at all)

Using a symbol was to make it clear that this is supposed to be a reference
to an actual variable and not some weird mini-programming language inside a
string or whatever.

It would be better to have some kind of abstract representation of *all*
the bootloader things one could want, in Guix in config.scm.
That would make Guix system a lot more complicated, though (chainloading
bootloaders for one--I saw you working on this, too).

Just to be clear, I'm fine with changing boot-parameters, but be very very
careful that all old versions of Guix and new versions of Guix can handle
all the boot-parameters--at least falling back to something.  It's not fun
if you can't boot anymore.  Source: I modified a lot of that stuff and
wasn't able to boot quite often until I finally stopped overcomplicating
the boot-parameters.

>Actually there is a problem with all this in guix: There is (bootloader 
>(target …)),
>which gives the impression that one is able to freely chose a folder for the
>bootloader files. However, the path “/boot/grub.cfg” is kind of hard coded.

Could you elaborate why having that hard-coded file path is bad?

It makes booting a lot more resilient if it's hard-coded as opposed to having
basic stuff like that configurable--and being careful all the time it's
actually configured correctly for all the parties to it, some of them maybe
not even inside Guix.

pgpciCwmdP1Qb.pgp
Description: OpenPGP digital signature