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

[Danny Milosavljevic]

Hi Stefan,

On Sun, 24 May 2020 15:09:02 +0200
Stefan <address@hidden> wrote:

> Hm, if I select an older system generation in GRUB, than that older one is 
> booted. But this doesn't change the bootloader.

Correct.  It doesn't need to since it just changes which Linux kernel will be 
booted temporarily, including what system and so on.

"System" here excludes $HOME.

Since the guix package manager itself is in $HOME, I think that that doesn't 
revert though.

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

You are totally right O_O

reinstall-bootloader says:

>          ;; Only install bootloader configuration file.

What happened here?  Why?!

(I think we should document these bootloader Guix intricacies in some better 
place than the mailing list archives; can't keep the thing straight otherwise 
:P)

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

It should be able to since guix package manager including package definitions 
is in $HOME, which is not rolled back, I think.  The only way to install the 
very recent GRUB is guix system reconfigure, and that will totally be able to 
see the newest guix packages.

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

Yes, that case is fine.

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

I think guix-the-package-manager is not reverted, so it will be able to see the 
newest installable stuff. 

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

No, that is per-user and not per-system.

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

No.

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

I think the actual bootloader (any of them those worked before) should be 
reinstalled by guix system delete-generations too, but apparently it doesn't do 
it right now.
Sounds very dangerous.  Doesn't that mean if one changed bootloaders in the 
past and then keeps using guix system delete-generations, that one eventually 
couldn't boot anymore?  O_O

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

I think guix-the-package-manager is still the newest one even after selecting 
an older system generation.

So the "brand new bootloader" case should be fine.
But the delete-generation case basically would have had to do the actual 
bootloader installation too.  Like it is now, it totally has a huge problem.

A possible way around having to know which bootloader is in use would be to 
just always install the configurations for all the known bootloaders.

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

Yes.

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

Yep.

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

Correct.

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

That sounds like a huge can of worms to open.  Better would be some kind of 
bootloader detector (can package "os-prober" do it maybe?)--or better yet, just 
also install the bootloader each time a system generation is deleted and/or 
system in reconfigured.  That was the original plan.

pgpLH5lhY2dV7.pgp
Description: OpenPGP digital signature