Hi, John Paul Adrian Glaubitz wrote: > What's the alternative HFS+ tree of the ISO? Does it write a small HFS+ > filesystem onto the ISO image?
Alternative trees are tradition in ISO 9660: Joliet, ISO 9660:1999, UDF. They can refer to the same data file content as the ISO 9660 tree, but have their own entry points and their own file names and meta data. The optional HFS+ tree created by libisofs has an Apple Partition Map slot as entry point which leads to the superblock of the HFS+ tree. (From then on you'd have to ask Vladimir Serbinenko about details.) A grub-mkrescue ISO for PC-BIOS and amd64 EFI bears 3 APM partitions: $ xorriso -indev grub-mkrescue-original.iso -report_system_area plain ... Media summary: 1 session, 7712 data blocks, 15.1m data, ... ... APM : N Info APM block size : 2048 APM gap fillers : 2 APM partition name : 1 Gap0 APM partition type : 1 ISO9660_data APM start and size : 1 16 1508 APM partition name : 2 HFSPLUS_Hybrid APM partition type : 2 Apple_HFS APM start and size : 2 1524 6026 APM partition name : 3 Gap1 APM partition type : 3 ISO9660_data APM start and size : 3 7550 162 Partition 2 starts at 2048-byte-block 1524, size 6026 blocks. It points to the HFS+ tree and includes the whole data content range of the ISO image, except the content of /efi.img (i wonder why): $ xorriso -indev grub-mkrescue-original.iso -find / -sort_lba -exec report_lba -- ... Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 84 , 1440 , 2949120 , '/efi.img' File data lba: 0 , 1668 , 0 , 0 , '/empty-file.txt' File data lba: 0 , 1668 , 0 , 0 , '/mach_kernel' File data lba: 0 , 1670 , 666 , 1363292 , '/boot/grub/fonts/unicode.pf2' ... File data lba: 0 , 7547 , 1 , 19 , '/System/Library/CoreServices/.disk_label.contentDetails' Partition 1 guards the ISO 9660 tree metadata and the data of /efi.img. Partition 3 guards the end padding of 300 KiB and the end alignment to full 64 KiB chunks. The trick how to combine GPT and APM in the same image relies on the fact that APM has an adjustable block size and that the readers of APM don't take offense from a fabricated APM Block0 which is crafted to be x86 machine code without any side effects. So the first 512 bytes of the image can serve as MBR x86 boot code and as APM Block0 at the same time. The APM block size of 2048 causes the next APM block to begin after the end of the GPT header block. The GPT header lets its GPT array begin after the end of the APM. Details are documented in https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt "SYSLINUX isohybrid for MBR, UEFI and x86-Mac" Inventor of this stunt is Matthew J. Garrett. See: "Anatomy of a Fedora 17 ISO image" https://mjg59.dreamwidth.org/11285.html The Fedora ISOs contain a small HFS+ image as data file. The APM then points to this image. (I once proposed this layout to you when we discussed the inclusion of a HFS tree (without "+") in xorriso.) With GRUB the dummy x86 code is slightly different from the one of SYSLINUX. In Hex: 45 52 08 00 eb 02 ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 eb 49 24 12 0f 09 And as said, other than with Fedora ISOs, the HFS+ tree is not part of an inner image file but rather covers nearly the whole data content of the ISO. Have a nice day :) Thomas

