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

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

For the nomenclature: "USB" alone is misleading because there are
also optical drives attachable to USB. Better distinguish the boot
media families CDROM (CD, DVD, BD) and HDD (hard disk, USB stick,
memory card, ...). 


adrian15 wrote:
> Grub-pc would be the one installed to be boot but syslinux files would be
> there for Multi-USB tools to know how to understand the iso and put it into
> an USB.

You mean the capability to boot the ISO via BIOS from USB stick ?
(Known with SYSLINUX as "isohybrid".)

grub-pc is supposed to be bootable that way too. Have a look at the
result of grub-mkrescue.
When running xorriso -as mkisofs, the decisive trick of grub-mkrescue
for BIOS bootability from HDD is:

  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img

(It is obvious that only one bootloader can put its MBR at the
start of the ISO. So additional -isohybrid-mbr for SYSLINUX
would conflict.)

CDROM bootability via BIOS is caused by

   -b boot/grub/i386-pc/eltorito.img \
     -no-emul-boot -boot-load-size 4 -boot-info-table \
     --grub2-boot-info 

(Options learned from grub-mkrescue tests on Debian Sid.)


> --bootloaders="syslinux,grub-efi,syslinux-efi"

Here i wonder whether (or how) your syslinux-efi boots out of an
ISO 9660 filesystem. My current knowledge is that SYSLINUX cannot
do this.


> Now primary means: "First lure" and secondary means "Second lure" by your
> definition.

There are normally two lures per firmware-hardware combination.
Depending on the medium, the lures are recognized in El Torito,
or in MBR, or in partition tables. 

In general we have theses dimensions
  {Medium: CDROM, HDD} x
  {Firmware: BIOS, EFI, ... exotic others ...} x
  {Hardware: i386, amd64, ... exotic others ...}

Not all tuples chosen from these sets are valid and not all
valid tuples can be combined in one ISO filesystem.
But the 8 main combinations for PC hardware are valid and
combinable.

I would avoid ranking terms like "first" or "primary".
Job descriptions for bootloaders could rather look like
  (CDROM + HDD, BIOS, i386 + amd64)
  (HDD, EFI, i386)
  (HDD, EFI, amd64)

Some of them can hardly be separated from each other.
E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical
technical properties.

  
> Given the way that both grub-efi and syslinux-efi use:
> /efi/boot/bootia32.efi
> and
> /efi/boot/bootx64.efi
> the last one to be run would overwrite the first one efi files.

You could combine bootia32.efi from the one boot loader and
bootx64.efi from the other boot loader, if you find a use case
for that stunt.
Without such a use case, i would decide for one boot loader per
firmware. Just to keep things simple.


> So... How would you go about for a:
> --bootloaders="syslinux,grub-efi,syslinux-efi"

I'd state that you don't need syslinux-efi if you have grub-efi
which is much better exercised with ISO 9660.

As said, nobody ever reported about success of SYSLINUX from
CDROM via EFI. I dimly remember that hpa, the author of SYSLINUX,
once stated on syslinux@zytor.com that the capability was missing
in SYSLINUX EFI to hop from the FAT filesystem into the ISO filesystem.


> they would overwrite their /efi/boot/boot*efi files ?

The EFI startup binaries of grub-efi and syslinux-efi would conflict
inside your FAT filesystem, indeed. There are supposed to be ways to
solve this conflict and offer the choice at boot time. For that you'd
need to have own EFI startup binaries which then hop on the programs
of one of the offered boot loaders.

But, well, what would be the use case for such a choice ?


Have a nice day :)

Thomas