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

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

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/
Reply to: