Documented probable isohybrid.c bugs and polished overview table.

doc/boot_sectors.txt

@@ -411,17 +411,19 @@ Sources:
 
 >>> Motivation: What systems will use the additional data ? amd64 UEFI ?
 
-This is a very condensed format which exposes as many entry points for boot
+This is a very condensed format which exposes a lot of entry points for boot
-firmware as possible.
+firmware.
 
-  Byte Range   | Value      | Meaning (all numbers are stored big endian)
+  Byte Range   | Value      | Meaning
 -------------- | ---------- | -------------------------------------------------
      0 -   511 | mbr        | Isohybrid MBR pointing to x86 boot image file,
                |            | with three entries in its partition map.
                |            | It shares its first 32 bytes with apm_head.
      0 -    31 | apm_head   | Mock-up of the start of the first block of
                |            | an Apple Partition Map (APM).
-   446  -  461 | mbr_entry1 | Partition table entry 1 describing ISO image size
+   446  -  461 | mbr_entry1 | Partition table entry 1 describing the size of
+               |            | the ISO image plus the backup GPT, padded up to
+               |            | the next full MiB.
    462  -  477 | mbr_entry2 | Entry 2 describing the UEFI VFAT boot image.
    478  -  493 | mbr_entry3 | Entry 3 describing the HFS+ boot image.
                |            |
@@ -443,6 +445,13 @@ firmware as possible.
 -------------- | ---------- | -------------------------------------------------
 
 
+For the purpose of booting, there may be two EFI boot image files in the
+ISO image. A VFAT image and a HFS+ image. The content of both is not in the
+scope of this document.
+These boot images get announced by EL Torito boot catalog entries with
+Platform Id 0xef.
+
+
 Newer SYSLINUX MBR templates begin by 32 bytes of machine code which are
 intentionally non-essential:
    33  ed  90  90  90  90  90  90  90  90  90  90  90  90  90  90
@@ -453,8 +462,8 @@ The following 32 bytes from block 0 of an Apple Partiton Map (APM) are such
 harmless code. They stem from Fedora-LiveCD.iso by Matthew Garret:
    45  52  08  00  00  00  90  90  00  00  00  00  00  00  00  00
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-It is a constant that does not depend on any properties of the ISO image or
+They do not depend on any properties of the ISO image or the information
-the information that is described in the following text.
+that is described in the following text.
 
 The layout of a Block0 of an APM is:
 
@@ -475,13 +484,6 @@ Byte Range | Value      | Meaning (all numbers are stored big endian)
 (The block_count of 0x9090 is pure fantasy. It shall only mark the disc as
  not empty.)
 
-
-For the purpose of booting, there may be two EFI boot image files in the
-ISO image. A VFAT image and a HFS+ image. The content of both is not in the
-scope of this document.
-These boot images get announced by EL Torito boot catalog entries with
-Platform Id 0xef.
-
 The data block ranges of the two EFI boot images get described by MBR
 partition entries 2 and 3, which thus claim blocks inside of partition 1.
 This partition nesting is acceptable to some EFI implementations only if the
@@ -531,8 +533,10 @@ Byte Range | Value      | Meaning (little endian numbers, LBA unit is 512 byte)
   20 -  23 | reserved   | = 0
   24 -  31 | curr_lba   | Location of this header block = 0x1
   32 -  39 | back_lba   | Location of header backup block = 0x144ffe = 1331198
-                        | This is 1 KiB before the end of MBR partition 1.
+           |            | This is 1 KiB before the end of MBR partition 1
-                          >>> ??? why 1 KiB and not 512 bytes ?
+           |            | (but should be 512 bytes).
+           |            | (Potential isohybrid.c bug #1:
+           |            |  Backup GPT is dislocated by 512 bytes.)
   40 -  47 | first_lba  | First usable LBA for partitions = 0x30 = 48
   48 -  55 | last_lba   | Last usable LBA for partitions  = 0x144fde = 1331166
   56 -  71 | guid       | Disk GUID
@@ -591,7 +595,7 @@ Byte Range | Value      | Meaning (all numbers are stored big endian)
    8 -  11 | start_block| "physical block start of partition" = 1
   12 -  15 | block_count| "physical block count of partition" = 16
            |            | (The value of 16 claims the ISO 9660 PVD as part of
-           |            |  the partition table. This might be unhealthy.)
+           |            |  the partition table. It should be 4 instead.)
   16 -  47 | name       | Partition name = "Apple"
   48 -  79 | type       | Type string = "Apple_partition_map"
   80 -  83 | lb_start   | Logical block start = 0
@@ -608,6 +612,10 @@ Byte Range | Value      | Meaning (all numbers are stored big endian)
  136 - 511 | reserved   |
 ---------- | ---------- | ----------------------------------------------------
 
+(Potential isohybrid.c bug #2:
+ Apple partition map entries bear the block count for blocks of 512 bytes
+ whereas Apple Block0 announces blocks of 2048 bytes.)
+
 The next Apple partition map entry is at byte 0x1000 = 4096:
 
    50  4d  00  00  00  00  00  03  00  00  00  29  00  00  04  70
@@ -619,15 +627,17 @@ The next Apple partition map entry is at byte 0x1000 = 4096:
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
    00  00  00  00  00  00  04  70  00  00  00  33  00  00  00  00
 
-3 partitions, start block is 0x29 = 41, block count is 0x0470 = 1136,
+3 partitions, start block is 0x29 = 41,
-name is "EFI", type is "Apple_HFS"
+block count is 0x0470 = 1136 (should be 284), name is "EFI",
->>> although this is a FAT image
+type is "Apple_HFS" (although this is a FAT image),
-, logical block start = 0, lb_count = 1136,
+logical block start = 0, lb_count = 1136 (should be 284),
 flags = 0x33 : valid, allocated, readable, writable.
-This points to file /isolinux/efiboot.img in the ISO image,
+This points to file /isolinux/efiboot.img in the ISO image.
->>> but misrepresents its size of 284 blocks of 2048.
+(Potential isohybrid.c bug #2:
+ Apple partition map entries bear the block count for blocks of 512 bytes
+ whereas Apple Block0 announces blocks of 2048 bytes.)
 
-At byte 0x1800 = 6144, there is map entry 3:
+At byte 0x1800 = 6144, there is Apple partition map entry 3:
 
    50  4d  00  00  00  00  00  03  00  00  01  51  00  00  08  c0
    45  46  49  00  00  00  00  00  00  00  00  00  00  00  00  00
@@ -639,14 +649,13 @@ At byte 0x1800 = 6144, there is map entry 3:
    00  00  00  00  00  00  08  c0  00  00  00  33  00  00  00  00
 
 3 partitions, start block is 0x0151 = 337 (LBA of /isolinux/macboot.img),
-block count = 2240
+block count = 0x08c0 = 2240 (should be 560), name is "EFI",
->>> (4 times higher than ISO size of 560 blocks)
+type is "Apple_HFS", logical block start = 0, lb_count = 2240 (should be 560),
-, name is "EFI", type is "Apple_HFS", 
-, logical block start = 0, lb_count = 2240,
 flags = 0x33 : valid, allocated, readable, writable.
+(Potential isohybrid.c bug #2:
+ Apple partition map entries bear the block count for blocks of 512 bytes
+ whereas Apple Block0 announces blocks of 2048 bytes.)
 
-
->>> GPT partitions marking ISO image, VFAT image within, HFS+ image within 
 At byte 0x2000 = 8192 begins the GPT partition array.
 It ends at byte 0x4000 = 16384.
 
@@ -666,7 +675,7 @@ A GPT partion entry looks like:
 
 Byte Range | Value      | Meaning (numbers are stored little endian)
 ---------- | ---------- | ----------------------------------------------------
-   0 -  15 | type_guid  | Partition type guid = Basic data partition
+   0 -  15 | type_guid  | Partition type GUID = Basic data partition
            |            | Wikipedia: "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7"
            |            | (Note: The first three words are shown byte swapped)
   16 -  31 | part_guid  | Unique partition GUID
@@ -675,14 +684,17 @@ Byte Range | Value      | Meaning (numbers are stored little endian)
   32 -  39 | start_lba  | First LBA = 0
   40 -  47 | end_lba    | Last LBA (inclusive) = 0x144828 = 1329448
            |            | This is the ISO image size in blocks of 512.
-                          >>> But it should be 1 block less than that
+           |            | (Potential isohybrid.c bug #3:
+           |            |  The end_lba in the first GPT entry should be 1 less
+           |            |  than the count of 512 byte blocks of the ISO image.)
   48 -  55 | flags      | Attribute flags
            |            | bit0= "System Partition" Do not alter.
            |            | bit2= Legacy BIOS bootable (MBR partition type 0x80)
            |            | bit60= read-only
-  56 - 127 | name       | >>> Wikipedia says UTF-16LE.
+  56 - 127 | name       | Wikipedia says UTF-16LE.
-           |            | >>> The name in Fedora-LiveCD.iso is 8 bit and result
+           |            | (Potential isohybrid.c bug #4:
-           |            | >>> of faulty memory operation on a text constant.
+           |            |  The name in Fedora-LiveCD.iso is 8 bit and result
+           |            |  of faulty memory operation on a text constant.)
 ---------- | ---------- | ----------------------------------------------------
 
 Next entry is at 0x2800 = 10240:
@@ -701,7 +713,8 @@ Next entry is at 0x2800 = 10240:
 Partition type GUID : "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7" = Basic data
 Start at block 0xa4 = 164 * 512 = 41 * 2048. The VFAT image file.
 Last block is 0x0513 = 1299 = 164 + 1135. This end is correct.
->>> The name is an unintentional patchwork in an 8 bit character set.
+(Potential isohybrid.c bug #4:
+ Wrong character set and incidential bytes in GPT partition name.)
 
 Next entry at byte 0x02100 = 8448:
 
@@ -719,7 +732,8 @@ Next entry at byte 0x02100 = 8448:
 Partition type GUID : "48465300-0000-11AA-AA11-00306543ECAC" = HFS+
 Start block is 0x0544 = 1348 * 512 = 337 * 2048. The HFS+ image file.
 Last block is  0x0e03 = 3587 = 1348 + 2239. Correct.
->>> Frankenstein's name, again. 
+(Potential isohybrid.c bug #4:
+ Wrong character set and incidential bytes in GPT partition name.)
 
 The rest of the System Area is 0 up to the Primary Volume Descriptor
 at block 16.
@@ -731,12 +745,16 @@ at least 16.5 KiB, which effectively occupy 18 KiB.
 
 The backup partition array is stored 17 KiB before the end of MBR partition 1
 resp. the image file.
->>> why not 16.5 KiB before end ? Wikipedia suggests "LBA -33" counted from end.
+(Potential isohybrid.c bug #1:
+ Wikipedia suggests "LBA -33" counted from end. This would be 16.5 KiB before
+ end.)
+
 The content of the partition arry is the same as the one of the primary array
 at byte 0x4000.
 
 The GPT header is stored 1 KiB before the end of MBR partition 1.
->>> why not 512 byte before end ? Wikipedia suggests "LBA -1" counted from end.
+(Potential isohybrid.c bug #1:
+ Wikipedia suggests "LBA -1" counted from end. This ould be 512 bytes.)
 
    45  46  49  20  50  41  52  54  00  00  01  00  5c  00  00  00
     E   F   I       P   A   R   T
@@ -749,8 +767,9 @@ The GPT header is stored 1 KiB before the end of MBR partition 1.
 It differs by its own CRC and by some of its parameters:
 Own address is 0x144ffe. The backup lba is 0x01 = Primary GPT header.
 Partition entries start is 0x144fde
->>> This overlaps with the last usable LBA. The backup GPT must move up by
+(Potential isohybrid.c bug #1:
->>> 512 bytes.
+ This overlaps with the last usable LBA. The backup GPT must move up by
+ 512 bytes.)
 
 
 ------------------------------------------------------------------------------