Syslinux - Feb 2016 - How to understand partition table on hybrid ISO image?

Hi,

if I inspect an hybrid ISO with tools like fdisk and gdisk, then looks
like hybrid ISO has both the MBR and GPT in order to support both the
BIOS and UEFI:

# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer:


If I inspect the disk with fdisk then it looks broken because inside a
larger partition is a smaller one which should be impossible:

# fdisk -l /dev/sdb

Disk /dev/sdb: 7.5 GiB, 8036285952 bytes, 15695871 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4a2bafa7

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 1284095 1284096  627M  0 Empty
/dev/sdb2        8568    9399     832  416K ef EFI (FAT-12/16/32)

#


When I try to understand what an hybrid ISO is, then looks like it is
a regular(according to El Torito standard) bootable ISO, which is
post-processes with isohybrid(?).
Isohybrid(https://gist.github.com/jsarenik/e184b4061263dbd7d3a3) seems
to add simply MBR to ISO. Is there anything else which makes a regular
bootable ISO to hybrid ISO? In addition, how should one understand
partition table on hybrid ISO image?



thanks,
Martin

Hi,

My thanks to Didier for the xorriso explanations.
I am looking since years for an author who would write a user's guide
that foresees the questions of real users. :))


Now for some background and history:

Martin T wrote:
> If I inspect the disk with fdisk then it looks broken because inside a
> larger partition is a smaller one which should be impossible:
It is well possible. Just not really legal.

As well as having GPT but no Protective MBR Partition,
and faking an Apple Block 0 which actually is x86 machine code
that really boots a BIOS machine.

> When I try to understand what an hybrid ISO is, then looks like it is
> a regular(according to El Torito standard) bootable ISO, which is
> post-processes with isohybrid(?).
Classic isohybrid is a BIOS MBR with x86 code that hops onto the El Torito
boot image of ISOLINUX.
(I would point to the SYSLINUX wiki, but it is "experiencing technical
 difficulties" right now
   http://www.syslinux.org/wiki/index.php/Isohybrid
 "(Can't contact the database server: No such file or directory
(localhost))"
)

> Is there anything else which makes a regular bootable ISO to hybrid ISO?
isohybrid is not irregular, to be clear. ECMA-119 (aka ISO 9660)
reserves the first 32 KB of an ISO as "System Area" for arbitrary
purposes. We choose to store an MBR and more in this range.

> In addition, how should one understand partition table on hybrid ISO image?
The EFI/Mac enhanced isohybrid layout stems from Matthew J. Garrett's
work on Fedora Live CD. He announced success in
  http://mjg59.dreamwidth.org/11285.html
I believe his adventure begins on
  http://mjg59.dreamwidth.org/?skip=140

It looks like he first wanted to work with real GPT by having only
one MBR partition of type 0xee which reaches from LBA 1 to the end
of the device. (Together with backup GPT at the end, this actually
would need adjustment when the ISO gets onto the USB stick.)

But then obviously some machines did not like GPT and wanted the
medium Legacy method of booting from an MBR partition of type 0xef.
At that point, i am not sure whether Matthew tested if omitting the
GPT would exclude from booting any of the so far tested machines.
The need to give further MBR partitions the type 0x00 indicates
that some EFI implementation does demand GPT constraints to be
obeyed. (Besides one single partition of type 0xee, GPT allows only
type 0x00 or size 0. UEFI 2.4, 5.2.1 and table 15 in 5.2.3.)

The method to boot via MBR partition 0xef is specified in UEFI 2.4,
"5.2.1 Legacy Master Boot Record (MBR)", not to be confused with
"Legacy" BIOS emulation mode which would run the x86 machine code
at byte 0 of the MBR.

Some x86 Macs want "blessed" files in HFS+, which they detect by
an entry in an Apple Partition Map. It is a lucky incident that one
can fake the initial block of such an APM in a way that has no
undesired side effects when executed as x86 machine code.
This way, BIOS MBR and APM can co-exist.

This here got produced by genisoimage and isohybrid -u -m, afaik:
------------------------------------------------------------------
Drive current: -indev 'Fedora-Workstation-netinst-x86_64-23.iso'
...
System area summary: MBR isohybrid cyl-align-on GPT APM
ISO image size/512 : 844528
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x80  0x00            0       845824
MBR partition      :   2   0x00  0xef          180        10780
MBR partition      :   3   0x00  0x00       684488        43168
MBR partition path :   2  /images/efiboot.img
MBR partition path :   3  /images/macboot.img
GPT                :   N  Info
GPT disk GUID      :      2544134511a4c545b120ccf9f988055d
GPT entry array    :      16  128  overlapping
GPT lba range      :      48  845790  845823
GPT partition name :   1  490053004f004800790062007200690064002000490053004f00
GPT partname local :   1  ISOHybrid ISO
GPT partition GUID :   1  639e1f980d5de640ad771229bb88ac5c
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x0000000000000000
GPT start and size :   1  0  844528
GPT partition name :   2  490053004f00480079006200720069006400
GPT partname local :   2  ISOHybrid
GPT partition GUID :   2  c2a9136420992c4289062b989989f841
GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   2  0x0000000000000000
GPT start and size :   2  180  10780
GPT partition path :   2  /images/efiboot.img
GPT partition name :   3  490053004f00480079006200720069006400
GPT partname local :   3  ISOHybrid
GPT partition GUID :   3  c2a9136420992c4289062b989989f841
GPT type GUID      :   3  005346480000aa11aa1100306543ecac
GPT partition flags:   3  0x0000000000000000
GPT start and size :   3  684488  43168
GPT partition path :   3  /images/macboot.img
APM                :   N  Info
APM block size     :      2048
APM gap fillers    :      0
APM partition name :   1  EFI
APM partition type :   1  Apple_HFS
APM start and size :   1  45  2695
APM partition path :   1  /images/efiboot.img
APM partition name :   2  EFI
APM partition type :   2  Apple_HFS
APM start and size :   2  171122  10792
APM partition path :   2  /images/macboot.img
------------------------------------------------------------------

Vladimir Serbinenko, the author of GRUB2, on the other hand insists
in UEFI compliant partitions:

------------------------------------------------------------------
Drive current: -indev 'grub-mkrescue-original.iso'
...
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM
ISO image size/512 : 30848
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xee            1        30847
GPT                :   N  Info
GPT disk GUID      :      07f29bb153383349a5ecd605dcf5ebd6
GPT entry array    :      20  176  separated
GPT lba range      :      64  30802  30847
GPT partition name :   1  4700610070003000
GPT partname local :   1  Gap0
GPT partition GUID :   1  07f29bb153383349a5e8d605dcf5ebd6
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x1000000000000001
GPT start and size :   1  64  272
GPT partition name :   2 
450046004900200062006f006f007400200070006100720074006900740069006f006e00
GPT partname local :   2  EFI boot partition
GPT partition GUID :   2  07f29bb153383349a5e9d605dcf5ebd6
GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags:   2  0x1000000000000001
GPT start and size :   2  336  5760
GPT partition path :   2  /efi.img
GPT partition name :   3  48004600530050004c0055005300
GPT partname local :   3  HFSPLUS
GPT partition GUID :   3  07f29bb153383349a5ead605dcf5ebd6
GPT type GUID      :   3  005346480000aa11aa1100306543ecac
GPT partition flags:   3  0x1000000000000001
GPT start and size :   3  6096  24104
GPT partition name :   4  4700610070003100
GPT partname local :   4  Gap1
GPT partition GUID :   4  07f29bb153383349a5ebd605dcf5ebd6
GPT type GUID      :   4  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   4  0x1000000000000001
GPT start and size :   4  30200  600
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
------------------------------------------------------------------

I personally (shrugging off some legacy Macs) would prefer this,
which would be feasible for isohybrid, too:

------------------------------------------------------------------
Drive current: -indev 'grub-mkrescue-mbr_only-noprot.iso'
...
System area summary: MBR grub2-mbr
ISO image size/512 : 23856
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x80  0x83            0        23856
MBR partition      :   2   0x00  0xef        23856         5760
------------------------------------------------------------------

An upcomming feature of xorriso is able to mark an appended partition
as El Torito boot image. I.e. the boot image is not a data file in the
ISO and thus does not have to be present twice - inside and outside of
partition 1.


There is also the slightly frankensteinish ISO produce of OpenSuSE:
------------------------------------------------------------------
Drive current: -indev 'openSUSE-13.1-NET-x86_64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR isohybrid cyl-align-off
Media summary: 1 session, 145356 data blocks,  284m data,  744g free
Volume id    : 'openSUSE-13.1-NET-x86_640091'
System area options: 0x00000202
System area summary: MBR isohybrid cyl-align-off
ISO image size/512 : 581424
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xef          280         8192
MBR partition      :   2   0x80  0x17         8472       573160
MBR partition path :   1  /boot/x86_64/efi
------------------------------------------------------------------

It stems from two nearly identical ISOs which differ by a big data
file after the directory tree of the larger one. The head of this
larger ISO is cut off together with the big file. Then it gets sewed
onto the head of the other. BIOS isohybrid is achieved by a run of
isohybrid before the head transplant.

The upper head serves as superblock for CD-ROM and /dev/sdX.
The large file serves as EFI partition and also claims the range
of the lower ISO head.

The lower head serves as superblock of partition 2, from which the
ISO is mountable. It does not show the large data file.

If its inventor is watching here: I am deeply impressed.
(We both seem to have the same ideas about a MBR-only EFI layout.)


As usual i have to ammend that no ISO is known which boots by
SYSLINUX EFI equipment. All known Linux ISOs have GRUB/GRUB2 software
in that partition. (There is the idea to put a whole operating system
into the EFI partition with SYSLINUX, which then should be able to break
out of that enclosure.)


To those who are still reading up to this point:

Have a nice day :)

Thomas