GNU bug report logs - #41066
[PATCH] gnu: grub: Support for chain loading.

Previous Next

Full log

View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Stefan <stefan-guix <at> vodafonemail.de>, Mathieu Othacehe <othacehe <at> gnu.org>, 41066 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: [bug#41066] [PATCH] gnu: bootloader: Support for chain loading.
Date: Sun, 25 Oct 2020 02:33:45 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Sat, 24 Oct 2020 18:22:48 +0200
Ludovic Courtès <ludo <at> 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 …))))

Nice!

I haven't used those before, so no idea whether it would be better here.

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

It doesn't prevent that API--but this narrow use case here doesn't need it.

And I do not intend to implement the general use case--we all decided against
general chainloading and then introduced full support for bootloaders other
than grub (which then do not chainload grub--they totally could have!).

But this use case with lots of bootloaders on an ESP partition (or Raspberry Pi
equivalent) is easy enough.  Maybe we should change the name of the main
procedure to be less general, though.  "chain-esp-bootloaders" ?

If you could check it out more, that would help.  I think how the patch is
now is fine for the narrow use case: chainloading the normal guix bootloader
using other bootloaders (or whatever else!  Maybe a turtle is loading the final
guix bootloader--who knows ;) ).

The code here can only chain bootloaders in the ESP partition (actually, the
Raspberry Pi equivalent of the latter).

> >>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 the patch:

>+(define (bootloader-profile packages package-contents files)
>[...]
>+  (profile (content (packages->manifest packages))
>+           (name "bootloader-profile")
>+           (hooks (list bootloader-collection))
>+           (locales? #f)
>+           (allow-collisions? #f)
>+           (relative-symlinks? #f)))

Maybe I don't understand what you mean... but that "profile" is from
(guix profiles).

In any case, maybe we should just call it "esp-bootloader-chain" or
maybe just "raspberry-pi-bootloader-chain".

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.