El 24/01/16 a las 16:51, Michal Suchanek escribió:
The model does not imply any ranking. "First", "Second", "Third"
could be justified, because there are lists in El Torito and
partition tables where the boot entries have to line up in sequence.
For my taste, "Main" or "Primary" too much implies a rank.
So... what about using:
FIRST_BOOTLOADER
and
SECOND_BOOTLOADER
instead of my current:
PRIMARY_BOOTLOADER
and
SECONDARY_BOOTLOADER
why not BOOTLOADERS?
The concept of being primary or secondary is just broken.
You can store 64 el-torito catalog entries on a CD. The different
entries are separated by -eltorito-alt-boot option. When you put the
CD with a BIOS and EFI entry in a machine that prefers UEFI the efi
entry is primary even when there is a CSM. When you put the CD into a
machine with legacy BIOS the BIOS entry is primary in the EFI one
useless.
There are some technical details like it is desirable to put the BIOS
entry before the EFI entry. This may be either enforced by reordering
the bootloader list automagically or just by setting the default to
syslinux,grub-efi and explaining in the docs that this is the usual
order and changing the order may potentially cause issues.
There are more technical details like the bootloader for i386 and
amd64 BIOS is the same one and on EFI it's two different binaries. Or
that when there is an EFI bootloader it's desirable to create another
e-torito entry for it as APM to boot on Macs. The technical details of
creating multiple partitions, boot entries, and whatnot are
implementation details. It's nice to document these details somewhere
for people who want to further butcher the created medium, add support
for more bootloaders, etc.
So basically what we have is support for two PC firmware types:
BIOS
EFI
and two bootloader alternatives for each firmware type
syslinux
grub
and for simlicity only one bootloader for one firmware type is
supported on single medium. Since booting on BIOS platform is well
supported with syslinux and booting on EFI platform is well-supported
with grub it is desirable to have the option to specify different
bootloader type for each supported platform and make it the default.
So rather than
BOOTLOADER=syslinux
BOOT_FIRMWARE=bios,efi
we have
BOOTLOADERS=syslinux,grub-efi
That is the bootloader name encodes the whole bootloader-firmware
pair. There is no need to specify more. It is well possible to specify
to not include 32bit efi binaries when building a 64bit CD build but
that's *-efi installation option and not a separate bootloader type.
This means the user can have 1-2 bootloaders on a single medium. And
if coreboot or whatnot support is added in the future there is
potential to have more.
Thanks
Michal
What you are describing here is what it's actually implemented in my
patch (Well, actually the first patch version because the current one
enforces bootloader roles). So what about primary and secondary terms?
Or first or second terms?
These terms are used in two places:
* Internal variables and functions to handle bootloaders
* Information shown to the final user
I'm most convinced to use the first and non-first notation. So that the
old code that referred to LB_BOOTLOADER can just refer to:
LB_FIRST_BOOTLOADER.
Later on, if we want to improve this old code we can modify it so that
it handles LB_BOOTLOADERS thanks to the bootloader functions directly.
I agree with you that a good approach would be to document the different
supported or suggested bootloader combinations rather than trying to
enforce it by code.
That would match my last thoughts which I quote here:
And, well, I have some ideas on how to add some special functions to
binary_bootloader files so that we have some sort of Object-Oriented / Hook
programming when defining what goes into the mkisofs options.
If you check current: binary_iso file it just relies on existing
binary_bootloaders without having an agnostic bootloader approach.
Here it's what I'm talking about:
https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145
case "${LB_PRIMARY_BOOTLOADER}" in
grub)
(...)
grub-pc)
(...)
esac
We could just invent the:
grub-pc-xorriso-options()
or
syslinux-xorriso-options()
functions which would be defined in:
binary_grub-pc
or
binary_syslinux
files
and handle all of these with only 3 or 4 lines of code.
E.g. binary_iso would add '-eltorito-alt-boot' just before a second bootloader
so that the bootloader only needs to take care of their own boot options.
Is there anyone opposed to such a big change on live-build handling of
bootloaders?
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/