[bug#41066] [PATCH] gnu: bootloader: Support for chain loading.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 23 Oct 2020 14:48:36 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>>   (bootloader-chain grub-efi-netboot-bootloader
>>                     (list (file-append u-boot "/libexec/u-boot.bin")
>>                           (file-append firmware "/firmware")))
>
> Ohhh!  That's right.  That's much better.  Can a profile be created with those
> in it?  Especially because of the profile hook...

Yes, there’s first-class <profile> objects that one can use in gexps:

  (profile (content (manifest (entries …))))

>> I think we should look at how to simplify this interface.  Intuitively,
>> I would expect the ‘bootloader-chain’ to take a list of <bootloader>
>> records and return a <bootloader> record.
>> Is this something that can be achieved?  If not, what are the extra
>> constraints that need to be taken into account?
>
> That is not easily possible, and is also logically not what happens anyway.
>
> The use case of this entire patchset is when one (for some reason) can't boot
> the final bootloader directly, then one uses some chain of bootloaders to
> get the final bootloader to boot.
>
> That especially means that all the bootloaders before the final bootloader
> WILL NOT GET THE GUIX GENERATIONS MENU.
>
> It is also pretty uncommon/impossible to use each usual bootloader installer
> in order to install all the bootloaders one after another.  Just think of
> what would happen if multiple x86_64 bootloaders all tried to install
> themselves into the first sector of the drive.  That's not gonna work
> correctly.
>
> What actually happens is that there's some kind of payload area in the first
> bootloader where you can put the second bootloader, and some kind of payload
> area in the second bootloader where you can put the third bootloader... and so
> on.  Except for the final bootloader, which has the Linux kernel in the payload
> area (as far as the final bootloader is concerned, it can do everything as if
> it was the first and only thing that was loaded at boot so far).
>
> That means the final bootloader can use the normal config files and generally
> proceed like all our standalone bootloaders do.  None of the previous bootloaders
> in the chain can do that, generally.

Sorry, I don’t see why this prevents an API that more closely matches
the idea of a chain of bootloaders (but perhaps I’d just need to spend
more time studying this.)

I guess my advice is: design an interface that’s as close as possible to
the concepts at hand.  If implementation details constrain what can be
done, that’s OK, but it should be clear in that case why we end up with
an interface that’s not as simple as one could expect.

>>bootloader-profile
>
>> Yes, if it’s about building a profile, you could just use a <profile>
>> object.  Would that work here?
>
> Huh?  Isn't he doing that already?
>
> That's what that procedure does.  Or am I misunderstanding?

It’s not using code from (guix profiles) IIRC.

>> >From a quick look at the patch, I don’t fully understand yet what’s  
>> going on.
>
> I suggested to Stefan to use a profile with a profile hook in order to
> configure all those bootloaders of a bootloader chain correctly.  That's
> what he does here.
>
> Usually, Guix bootloader *packages* have a lot of junk that (1) you wouldn't
> want on a esp partition (wastes space) and also stuff that would be duplicates
> with other bootloaders (COPYING etc).  Therefore, it's nice to be able to
> filter what files of those packages get used.  I think your suggestion in the
> beginning is the best one.  (file-append u-boot "/libexec/u-boot.bin") indeed!
> The profile hook can then use whatever methods to configure all those
> bootloaders correctly.

Alrighty!

Thanks,
Ludo’.