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

[Stefan]

Hi Danny!

> Am 24.05.2020 um 13:00 schrieb Danny Milosavljevic <address@hidden>:
> 
>> 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)

OK, I understand. I will take a look at it.

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

Hm, if I select an older system generation in GRUB, than that older one is 
booted. But this doesn't change the bootloader.
If I then delete some system generations – as I’ve seen so far, but I might be 
wrong – the bootloader is not reinstalled either. Only the grub.cfg is 
regenerated to remove the deleted generations. If I reboot, then I'm still 
using the latest generation GRUB, but boot some older system generation, which 
would not be able by itself to install this very recent GRUB in use.

If I then reconfigure the system, only then another GRUB - or even a different 
bootloader, depending on my etc/config.scm – will be installed and the 
according configuration file will be generated as well. Then again all will 
fit. In the worst case the (bootloader (bootloader-configuration …) …) in my 
etc/config.scm is still newer than this older guix system in use is able to 
handle. 

Oh, by the way, does booting an older system generation also change the guix 
version in use from the latest 'guix pull'? I don't think it does.

And does booting an older generation change the config.scm? I don’t think so 
either.

Actually, I don’t really understand what you mean. Are there circumstances 
beside a 'guix system reconfigure' in which the bootloader gets reinstalled? 
And with reinstall I don’t mean to only regenerate the grub.cfg, but calling 
/sbin/grub-install.

Isn’t the actual problem for an older running system generation to know which 
bootloder is currently in use? I think this can't be inferred by the currently 
running system generation. It may happen, that you use a brand new bootloader 
which is not known by the older system generation you just switched to.

But still then, if you invoke a 'sudo -E guix system delete-generations' or a 
'sudo -E guix system reconfigure' I think you still use the very latest guix 
version that you 'guix pull'-ed last. And that guix version should still know 
all brand new bootloader. The problem may “only” be to know for 'sudo -E guix 
system delete-generations' which one to use. But actually the bootloader-name 
field in /var/guix/profiles/system/parameters can't tell either, as it must be 
an older bootloader than the brand new one.

Maybe the information about the bootloader version in use needs to reside with 
the installed bootloader somewhere below /boot/efi/…? But this may be 
impossible for the legacy grub-bootloader.

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

I think after switching to an older system generation this is not true, as 
explained above. Am I wrong about this?

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

I see.

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

As I wrote a bit below: 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 Im still unsure about this.


Bye

Stefan