Re: Installer doesn't find the mirrors

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

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