Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
On 24 January 2016 at 00:41, adrian15 <adrian15sgd@gmail.com> wrote:
> El 23/01/16 a las 09:21, Thomas Schmitt escribió:
>>
>> There is a fourth dimension to be expressed: Bootloader.
>> Then there is the dimension of ISO filesystem objects.
>> A user wish would contain at least
>> ISO-Object, Bootloader, Medium, Firmware, Architecture
>>
>> E.g.
>>
>> Appended Partition, with GRUB2 content, for CDROM and HDD, via EFI, on
>> i386
>>
>> ISO Data File, with SYSLINUX content, for HDD, via BIOS, on i386 and
>> amd64
>>
>> I am not sure whether this list of more or less combinable
>> dimensions is complete yet.
>>
>> Further one will want to express whether the gaps between partitions
>> should be filled, which kinds of partition tables shall emerge, ...
>> These properties are global to the ISO, not specific to a single
>> boot image. Some are combinable, some are mutally exclusive.
>>
>> (Maybe it is time to break out an UML editor.)
>
>
> I propose you to send these concerns to live-wrapper project which has just
> begun and it's advertised as highly modular by Iain. It would be quite nice
> if all these concerns were properly addressed by Iain's tool.
>
> I am not saying that they are not welcomed to live-build but, right now, I
> think we should focus on making UEFI to boot and not re-thinking all the
> bootloader handling.
>
>> grub-mkrescue layout is rarely used for distro ISOs.
>> I blame this on the existing SYSLINUX based production software
>> for distro ISOs. In principle, a pure GRUB2 or a pure SYSLINUX
>> equipment appears to be the more reasonable choice.
>
>
> I once asked in a Debconf why the people were so stubborn to use syslinux
> instead of using grub2 (which seems technically superior to me). It would
> seem that the same people that maintain syslinux happen to maintain the
> kernel boot stack (or whatever it is called, I mean what happens just after
> the bootloader handling the execution to the kernel). So, that means, it's
> far easier to them to debug why the kernel is refusing to boot.
>
I was wondering that also. The GRUB is so cool and can do everything, right?
It also means it can crumble and fall apart in so many interesting ways.
I mean if you install grub on a LVM soft-RAID array and it then does
not boot you are wondering why it happened when it has all those RAID
modules. And you find that it has RAID modules only for the *previous*
revision of the LVM format.
So you do what you would plan for from the start with Syslinux - plug
in an USB stick and put a boot partition on it, yay.
Could have saved hours of debugging by going with the stupid limited
Syslinux from the start, right?
>>> Maybe we can just name them as:
>>> "Main bootloader"
>>> and
>>> "Alternate bootloader".
>>
>>
>> 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
Reply to: