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
