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

[Stefan <stefan-guix@vodafonemail.de>]

Hi Mathieu!


> Am 23.05.2020 um 10:02 schrieb Mathieu Othacehe <othacehe@gnu.org>:
> 
>> 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