guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan
Subject: [bug#41066] [PATCH] gnu: bootloader: Support for chain loading.
Date: Tue, 17 Nov 2020 21:27:42 +0100

Hi Danny!

> I've reviewed and pushed the first part (s;HOOK;HOOKS;) now as guix master
> commit ede4117f7f18e118003f2599f5c8e985dfbdf9a5.

OK, thanks.

> Could you explain what this is for in your use case?  I don't yet understand
> the reason for this complexity.

Sure.

> (1) Why is there a $output/collection subdirectory?  Is there something
> else than that in the profile output?  

The profile contains first of all the GRUB package with all its tools and 
files. This profile is the ‘package’ argument to the GRUB installer. Having the 
profile hook create the collection folder eases the task for an installer. The 
simple idea is to copy all the additional files along with the installed GRUB 
bootloader into /boot. Without the collection/ the installer would require the 
list of files as well and reimplement the same functionality as already inside 
the hook, to copy the files into the /boot/ folder.

For example the profile contains at least these folders from the grub package, 
plus the collection/:

/gnu/store/…-bootloader-profile/collection
/gnu/store/…-bootloader-profile/etc
/gnu/store/…-bootloader-profile/share
/gnu/store/…-bootloader-profile/lib
/gnu/store/…-bootloader-profile/bin
/gnu/store/…-bootloader-profile/sbin

But the /boot/ folder finally contains something like this, with most of it 
being content from the collection/, where the GRUB files get installed belaw 
/boot/efi/:

/boot/bcm2710-rpi-3-b.dtb
/boot/bootcode.bin
/boot/bootloader.txt
/boot/config.txt
/boot/custom.txt
/boot/efi/
/boot/fixup.dat
/boot/gnu/
/boot/grub/
/boot/overlays/
/boot/u-boot.bin

Actually one could say that the profile hook is a kind of ‘pre-installer’ for 
everything not related to GRUB, able to prepare everything, but unable to write 
into the /boot folder.

> If there are no good reasons to do it like that, I'd just put the
> profile into $output directly instead--it's easier to understand, and also 
> it's
> how other profiles are being used.

Not having the collection folder would mean that the installer would need to 
assume much more about the result of the profile hook, to copy the right files 
to /boot.

> (2) The COPY-FILES? flag is kinda weird.
> I would prefer if INSTALLER just defaulted to a procedure that: does copy
> files, and then calls the final bootloader installer.
> If the user doesn't want it then the user could still pass a INSTALLER
> that doesn't (for example the user could pass #:installer
> (bootloader-installer final-bootloader)).

Agreed. Another possibility would be to remove the collection folder within a 
hook.

> I would prefer if the user would just change the INSTALLER in the case he 
> wants
> to not use the profile (which is kinda weird?!) or pack it or whatever.

OK, I see, in case of a custom installer we can skip the copying completely. 
That makes sense. 

> (3) Why isn't the final bootloader installed last?  I would have expected
> it to be installed last so that if it does packing of the profile contents
> in order to quickly find it at boot, it would have to have all the files
> of the profiles already, no?

I thought about the order as well. My conclusion was that a file from the 
collection should be able to overwrite a file installed from final-bootloader, 
for example to install own device-tree files.

What do think?


Bye

Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]