Hi, On Fri, 23 Oct 2020 14:48:36 +0200 Ludovic Courtès 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 > records and return a 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 > 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.