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

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

Hi,

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

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

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]