[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)



Hi,

adrian15 wrote:
> * What is it a secondary bootloader?
> It's what happens when you request mkisofs that your bootloader to be 
> boot in second place or as a second partition. I don't know how it 
> actually works.

An ISO may contain several lures for boot firmware.

If it is booted from CD/DVD/BD, then the lures are in the El Torito
boot catalog. In case of debian-cd it contains two entries which
point to boot images. One entry is marked as suitable for BIOS and
one marked as suitable for EFI. The boot firmware then picks what
it deems right and starts it, or offers it to the user for starting.

If the ISO is presented on USB stick or alike, then BIOS looks
for the magic number of an MBR and if so, mindlessly executes
the x86 machine code that starts at byte 0 of the ISO.
This code then hops onto the same boot code that is advertised
by El Torito (because xorriso or isohybrid patched its block
address into the MBR code).

EFI looks on USB stick for an MBR partition of type 0xef or
for a single partition of type 0xee. In the latter case it assumes
the presence of GPT and looks for a GPT partition with type GUID
28732ac11ff8d211ba4b00a0c93ec93b.
Inside the found partition it expects a FAT filesystem and
particular binaries for each supported processor archictecture.
E.g. \EFI\BOOT\BOOTX64.EFI

The El Torito EFI boot image has the same content specification
as the EFI System Partition. Therefore both boot paths can share
the same data. 

My cheat sheet is at
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

-----------------------------------------------------------------

> So, I guess the -eltorito-alt-boot does the magic but I'm not sure. 
> Maybe someone else can explain it better than me.

-eltorito-alt-boot is simply a separator between the options of
El Torito boot images. 
I assume your first boot image is announced by -b and gets
the usual options
   -no-emul-boot -boot-load-size 4 -boot-info-table

Before the announcement of the EFI boot image begins, option
-eltorito-alt-boot is needed to protect your -b and its helpers
from being overwritten.

> So in grub-efi we just add to the xorriso options:
> -eltorito-alt-boot \
>  -e boot/grub/efi.img \
>  -no-emul-boot \
>  -isohybrid-gpt-basdat \
>  -isohybrid-apm-hfsplus

Here a second boot image gets announced by -e and the next three
options apply to it.


> And in syslinux-efi (currently) we add:
> -eltorito-alt-boot \
> --efi-boot boot/efi.img \

Option --efi-boot is a shortcut for
  -eltorito-alt-boot -e ... -no-emul-boot -eltorito-alt-boot
normally used by grub-mkrescue. The SYSLINUX community prefers -e.


> -append_partition 2 0x01 \
>  binary/boot/efi.img

I wonder what EFI firmware would hop on an MBR partition of type 0x01.
An EFI System Partition in MBR should have type 0xef to be recognized.

It looks like this variant will not get GPT. That's fully compliant
to UEFI 2.4. Just the MBR partition type should be 0xef.

(Does "syslinux-efi" mean that you can boot from ISO via EFI
and SYSLINUX stuff to an operating system ? That would be new.)

---------------------------------------------------------------

Above options do not produce HFS+ with blessing.
Option -isohybrid-apm-hfsplus causes an Apple Partition Map entry
which points to the data content of boot/grub/efi.img.

There are two ways known to me how to get a boot path via HFS+:
Fedora Live CD as of Matthew Garrett
or grub-mkrescue as of Vladimir Serbinenko.

---------------------------------------------------------------

Fedora Live, e.g. 
  Fedora-Live-Xfce-x86_64-rawhide-20150704.iso
is the ancestor of debian-cd's layout. It contains a small HFS+
filesystem image as ISO data file
  /isolinux/macboot.img

debian-cd does not have such an HFS+ image file.
Image content and production is out of my scope.

xorriso would only bond it to El Torito, MBR, GPT, and APM. I understand
that APM leads some Macs to that HFS+ filesystem. Whether there are
customers for GPT is unclear. The lures in El Torito and MBR are
probably unused.

The essential xorriso -as mkisofs options are a superset of those
of debian-cd for amd64:

  -isohybrid-mbr /path/to/isohdpfx.bin
  -apm-block-size 2048
  -c '/isolinux/boot.cat'
  -b '/isolinux/isolinux.bin'
    -no-emul-boot
    -boot-load-size 4
    -boot-info-table
  -eltorito-alt-boot
  -e '/isolinux/efiboot.img'
    -no-emul-boot
    -isohybrid-gpt-basdat
    -isohybrid-apm-hfsplus
  -eltorito-alt-boot
  -e '/isolinux/macboot.img'
    -no-emul-boot
    -isohybrid-gpt-hfsplus
    -isohybrid-apm-hfsplus

(Options picked out of proposal of
   xorriso -hfsplus on \
           -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \
           -report_el_torito as_mkisofs
)

No UEFI compliant firmware should use the GPT in there, because
the MBR partition table contains a partition of type other than
0x00 and 0xee. EFI firmware should rather follow the MBR partition
of type 0xef if the ISO is presented on USB stick.

---------------------------------------------------------------

If you install on Sid: grub-pc-bin, grub-efi-ia32-bin, grub-efi-amd64-bin
and run

  mkdir minimal_dir
  echo dummy payload >minimal_dir/dummy_payload
  grub-mkrescue -o output.iso minimal_dir

then you get an image.iso with HFS+, GRUB2 style.
By incident i was spying on grub-mkrescue recently.
The options used were

  -graft-points
  --modification-date=2016011614071900
  -b boot/grub/i386-pc/eltorito.img
    -no-emul-boot
    -boot-load-size 4
    -boot-info-table
    --grub2-boot-info
  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -hfsplus
  -apm-block-size 2048
  -hfsplus-file-creator-type chrp tbxj /System/Library/CoreServices/.disk_label
  -hfs-bless-by i /System/Library/CoreServices/boot.efi
  --efi-boot efi.img
  -efi-boot-part --efi-boot-image
  --protective-msdos-label
  -o output.iso
  -r
  /tmp/grub.ylUf65
  --sort-weight 0 /
  --sort-weight 1 /boot
  minimal_dir

/tmp/grub.ylUf65 was the disk tree with the GRUB files.

Here, the HFS+ filesystem gets created by xorriso (code contributed
by Vladimir Serbinenko).
Other than the Fedora layout, Vladimir's layout puts much emphasis
on disjoint partitions and pointing EFI towards GPT.

---------------------------------------------------------------

Have a nice day :)

Thomas


Reply to: