Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 13:38, Thomas Schmitt escribió:
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.
Interesting.
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).
Aha.
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
Great! I want to document the different ways of how BIOS boot, UEFI boot
and Secure Boot work and that might be helpful.
-----------------------------------------------------------------
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.
That it's quite interesting. Do you mean if you have:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
you could just re-arrange them as:
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
and it would be fine?
So that it's not strictly necessary for syslinux or grub-pc to be a
primary bootloader (or first lure in your definition) ?
That would also simplify my contributed code to live-build by not
needing to handle if a bootloader is primary/secondary or not.
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.
Ok.
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.
Knowing that I will probably expand that so that the syslinux-efi and
grub-efi options are more similar and we can compare them in a more easy
manner.
-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.
That needs to be asked to Hertzog. I just tried to use his original work.
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.)
I don't know what you mean by 'SYLINUX stuff to an operating system. I
understand that Hertzog work let's you boot into the cd booting by the
means of EFI. The EFI image needs to include the configuration file (as
opossed to the grub-efi implementation which only stores its
configuration file in the CD/DVD/BD media).
---------------------------------------------------------------
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.
If I'm not mistaken Hertzog removed that option because you suggested to
remove it on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66
Are you requesting to put this option back ?
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.
The debian-cd method is one of them? Or is it not?
---------------------------------------------------------------
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.
The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso
options are:
xorriso -as mkisofs -r \
-checksum_algorithm_iso md5,sha1,sha256,sha512 \
-V 'Debian 8.2.0 M-A 1' \
-o
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.iso
\
-jigdo-jigdo
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.jigdo
\
-jigdo-template
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.template
\
-jigdo-map Debian=/org/cdbuilder.debian.org/src/ftp/debian/ \
-jigdo-exclude boot1 \
-md5-list
/org/cdbuilder.debian.org/src/deb-cd/tmp/2multi-arch/jessie/md5-check \
-jigdo-min-file-size 1024 \
-jigdo-exclude 'README*' \
-jigdo-exclude /doc/ \
-jigdo-exclude /md5sum.txt \
-jigdo-exclude /.disk/ \
-jigdo-exclude /pics/ \
-jigdo-exclude 'Release*' \
-jigdo-exclude 'Packages*' \
-jigdo-exclude 'Sources*' \
-J -J \
-joliet-long \
-cache-inodes \
-isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin \
-b isolinux/isolinux.bin \
-c isolinux/boot.cat \
-boot-load-size 4 \
-boot-info-table \
-no-emul-boot \
-eltorito-alt-boot \
-e boot/grub/efi.img
-no-emul-boot \
-isohybrid-gpt-basdat \
-isohybrid-apm-hfsplus \
boot1 CD1
where you can see they use:
-isohybrid-apm-hfsplus
So... this is not useful for creating an HFS+ image file?
What does this option do instead then?
Or maybe your debian-cd information was outdated?
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.
I know that some Mac Book Pro s from 2010,2011 and so on use and
understand GPT by default. Actually if you want to produce, e.g. a
working Mac OS X installation disk I think it's compulsory to do it in a
GPT disk.
And, well, the Grub2 in git happens to generate an additional GPT disk
somehow in the same disk image for that matter. Maybe I'm just repeating
what you are going to saying later in this email about how Grub2 handles
boot in Mac systems.
The lures in El Torito and MBR are
probably unused.
Yeah, they 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
)
Interesting. I did not know that you could request what an ISO
'layout/configuration' was.
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.
Sorry but I'm not following you.
A) Are you complaining about syslinux-efi on:
-append_partition 2 0x01
that should be:
-append_partition 2 0xef
instead?
B) You are saying good things about -isohybrid-apm-hfsplus because it
avoids normal EFI firmware to read it? So that only Mac systems can read it?
---------------------------------------------------------------
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.
Yeah, I do a similar thing with Super Grub2 Disk 'hybrid' (
http://www.supergrubdisk.org/2015/05/03/super-grub2-disk-2-02s3-released/ )
version. Last time I checked it did not work ok in Debian because the
commit the grub package was based was too old.
The exact problem is that it did not boot in EFI mode when booted from a
USB device / hard disk.
I kind of complained here:
https://lists.debian.org/debian-efi/2016/01/msg00013.html but did not
manage to explain what the exact problem was.
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.
Interesting. That /System/Library is from Mac OS X systems, probably
from Mac OS X installation disks. And there's the bless part too. This
is quite interesting. It might be even more compatible with more systems
than debian-cd implementation. But, well, I'm not quite an expert myself
for claiming that statement right now.
Do you know if that Serbinenko contribution needs a minimal xorriso
version? (I just tried the -report_el_torito switch in Debian jessie and
it's not there. I was wondering if it would happen the same thing with
Serbinenko work. Debian Jessie version for xorriso is: 1.3.2 .)
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.
I see.
---------------------------------------------------------------
Have a nice day :)
Thank you for your valuable information.
Thomas
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: