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

[Stefan]

Hi Mathieu!


> Am 23.05.2020 um 10:02 schrieb Mathieu Othacehe <address@hidden>:
> 
>> It reads this information form /var/guix/profiles/system/parameters: 
>> (bootloader-name grub-efi-bootloader).
>> With this again the hard-coded path “/boot/grub.cfg” is used, ignoring any 
>> value overwritten in (configuration-file).
> 
> Oh, we need to fix that! It means that we would need to add a
> "bootloader-configuration-file" field to <boot-parameters> record, is
> that correct?

Yes, I would guess so. But I’m not sure, if the field bootloader-name can be 
dropped then from <boot-parameters>. But if, then we could probably also drop 
the field name from the <bootloader> record. 

>> Another issue is (install-dir (string-append mount-point "/boot")) in 
>> (install-grub-efi), which ignores any (configuration-file) setting, too – 
>> well, it has no access to that setting –, and implies at least “/boot” to be 
>> the prefix of (bootloader (target …)). 
>> 
>> Beside the wish to avoid this hard-coded “/boot“ assumption, I made this a 
>> function with two parameters for two more reasons. 
> 
> Could it be an option to infer the bootloader installation directory and
> the efi subdir from the install-grub-efi/install-grub-efi-net functions?
> If TARGET is /boot-nfs/efi/Guix", could we suppose that the
> boot-directory is "/boot-nfs" and the efi-subdir is "efi/Guix"?

For the new install-grub-efi-net I see first of all no issue in keeping it a 
function. This gives the needed flexibility.

For the existing grub-efi-bootloader the assumption seems to be that there will 
always be a /boot/grub.cfg. This is just not stated in the documentation. But 
it gave me the impression that there is some control about it with (bootloader 
(target …) …). But this is not the case. For the legacy grub-bootlouder the 
(bootloader (target …) …) needs to be a device, and the /boot/grub.cfg is 
implied and hard coded as well.

Actually thinking about it again, mounting the efi partition at e.g. /foo/efi, 
doesn't brake anything in the first place. Then GRUB will be installed at the 
target /foo/efi, basically into the efi partition it belongs. It will just read 
its configuration from /boot/grub.cfg, from a different partition.

The actual difference to the new grub-efi-net-bootloader is that it has only 
TFTP access to its files and its configuration file; there is only one place to 
lookup both, instead of two partitions in case of the grub-efi-bootloader.

For deleting system generations the path to the always present, not 
configurable /boot/grub.cfg is looked up. This works for the existing 
grub-efi-bootloader and grub-bootloader. But it does not work for the 
grub-efi-net-bootloader, because its configuration file does not live at 
/boot/grub.cfg, as its path is now implicitly configurable via (bootloader 
(target …) …). In addition for my setup I used a /boot-nfs folder instead of a 
/boot folder, and saw no benefit then in keeping the /boot folder.

I think there is a second possibility. It may be possible to create a symlink 
from /boot-nfs/efi/boot/grub.cfg to ../../../boot/grub.cfg. Then the assumption 
that there will always be a /boot/grub.cfg file stays valid. 

But personally I do not like this idea.

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.

> The make-grub-efi-net-bootloader macro is a nice hack, but I fear that
> it makes the bootloader configuration (even more) difficult.

At least it gives me the flexibility which was missing so far. I suggest to 
keep it for the moment and do a different patch once we are clear which way to 
go. If we add a bootloader-configuration-file field to the <boot-parameters> 
record, than the macro can be removed anyway.


Bye

Stefan