Documented MBR partitions and GUIDs

doc/boot_sectors.txt

@@ -375,13 +375,15 @@ Byte Range | Value      | Meaning
  446 - 509 | ========== | Partition table
            |            |
  446 - 461 | part_entry | Partition table entry 1 describing ISO image size
-           |            | starting at LBA 0. I.e. contrary to tradition.
+           |            | rounded up to the next full MiB. The partition starts
+           |            | at LBA 0. (I.e. contrary to tradition.)
            |            | See above for partition table entry format.
            |            |
  462 - 509 |          0 | Unused partition entries 2 to 4
  510 - 511 |     0xaa55 | MBR signature
 ---------- | ---------- | ----------------------------------------------------
 
+The ISO image file gets padded up to the next full MiB.
 
 hpa about MBR templates and partition table filesystem types:
 
@@ -404,6 +406,7 @@ Sources:
   http://opensource.apple.com/source/IOStorageFamily/IOStorageFamily-116/IOApplePartitionScheme.h (typedef struct Block0)
   http://www.informit.com/articles/article.aspx?p=376123&seqNum=3
   http://en.wikipedia.org/wiki/GUID_Partition_Table
+  http://en.wikipedia.org/wiki/GUID
   syslinux-4.05/utils/isohybrid.c
 
 >>> Motivation: What systems will use the additional data ? amd64 UEFI ?
@@ -450,6 +453,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
+the information that is described in the following text.
 
 The layout of a Block0 of an APM is:
 
@@ -470,6 +475,7 @@ 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.
@@ -481,6 +487,30 @@ 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
 type of partition 1 is 0x00.
 
+The MBR partition entry number 1 is
+   80  00  01  00  00  3f  a0  89  00  00  00  00  00  50  14  00
+It marks the partition as bootable, starting at block 0, with a size that
+is the smallest full MiB not smaller than the ISO image size + 18 KiB.
+(The 18 KiB are needed for the GPT backup.)
+The ISO image has a size of 332362 blocks of 2K = 1329448 * 512 = 649.14 MiB.
+The partition size is 0x145000 = 1331200 * 512 = 650 MiB.
+Start C/H/S = 0/0/1, type is 0x0 ("Empty"), end C/H/S is 649/63/32.
+
+Partition 2:
+   00  fe  ff  ff  ef  fe  ff  ff  a4  00  00  00  70  04  00  00
+Start block is 0xa4 = 164 * 512 = 41 * 2048. The VFAT image file.
+Partition size is 0x0470 = 1136 * 512. The size of that file.
+Start C/H/S = 1023/254/63, type 0xef (fdisk says: "EFI (FAT-12/16/"),
+end C/H/S =  1023/254/63.
+>>> ??? why are the C/H/S values so far out ? 
+
+Partition 3:
+   00  fe  ff  ff  00  fe  ff  ff  44  05  00  00  c0  08  00  00
+Start block is 0x0544 = 1348 * 512 = 337 * 2048. The HFS+ image file.
+Partition size is 0x08c0 = 2240 * 512. The size of that file.
+Start C/H/S = 1023/254/63, type 0x00 ("Empty"), end C/H/S =  1023/254/63.
+>>> ??? why are the C/H/S values so far out ? 
+
 
 The second 512-block in the ISO image is a GPT header.
 
@@ -501,14 +531,13 @@ 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
-                          >>> ??? That is 437.5 2K-blocks after the image end
+                        | This is 1 KiB before the end of MBR partition 1.
-                          >>> ??? which is at 332362 (* 4 = 1329448)
+                          >>> ??? why 1 KiB and not 512 bytes ?
-                          >>> ??? 1 MiB alignment ?
   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 / UUID = {
+  56 -  71 | guid       | Disk GUID
-           |            |      0x73, 0x23, 0xc8, 0x79, 0x19, 0xe6, 0x97, 0x4d,
+           |            | Random, produced by uuid_generate(),
-           |            |      0x95, 0x17, 0x69, 0x30, 0xc5, 0x38, 0xe2, 0x99 }
+           |            | 32,16,16 byte swapped
   72 -  79 | part_start | Partition entries start LBA = 0x10 = 16 = byte 0x2000
            |            | (This is unusual. It leaves room for the Apple
            |            |  partition map entries.)
@@ -525,11 +554,17 @@ chosen so that the CRC of 0 bytes of input is 0x00000000.
 The least significant bits of input bytes get processed first. I.e. bit0 of
 the last input byte gets mapped to x exp (7 + 32), bit7 of this byte gets
 mapped to x exp (0 + 32).
-The resulting division residue gets bit mirrored. E.g. bit0 becomes bit31,
+The resulting division residue gets bitwise mirrored. E.g. bit0 becomes bit31,
 bit1 becomes bit30, and so on. Further it gets exored with 0xffffffff.
 
-
+A GUID consists of a 32-bit integer, two 16-bit integers, and an array of
-The ISO image has a size of 332362 blocks of 2K = 1329448 blocks of 512.
+8 bytes. The integers are to be stored big-endian.
+A globally registered class GUID are the partition type GUIDs.
+This example uses two of them
+Basic data partition:  a2 a0 d0 eb , e5 b9 , 33 44 , 87 c0 68 b6 b7 26 99 c7
+HFS+ partition      :  00 53 46 48 , 00 00 , aa 11 , aa 11 00 30 65 43 ec ac
+Note that the wikipedia list shows the first 32-bit word and the next two
+16-bit words in little-endia interpretation.
 
 
 Because the block size was announced as 2048, the first Apple partition map
@@ -631,8 +666,12 @@ A GPT partion entry looks like:
 
 Byte Range | Value      | Meaning (numbers are stored little endian)
 ---------- | ---------- | ----------------------------------------------------
-   0 -  15 | type_guid  | Partition type guid = random
+   0 -  15 | type_guid  | Partition type guid = Basic data partition
-  16 -  31 | part_guid  | Unique partition GUID = random
+           |            | Wikipedia: "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7"
+           |            | (Note: The first three words are shown byte swapped)
+  16 -  31 | part_guid  | Unique partition GUID
+           |            | Random, produced by uuid_generate()
+           |            | 32,16,16 byte swapped
   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.
@@ -659,6 +698,7 @@ Next entry is at 0x2800 = 10240:
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
 
+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.
@@ -676,6 +716,7 @@ Next entry at byte 0x02100 = 8448:
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
 
+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. 
@@ -683,6 +724,35 @@ Last block is  0x0e03 = 3587 = 1348 + 2239. Correct.
 The rest of the System Area is 0 up to the Primary Volume Descriptor
 at block 16.
 
+
+The ISO image file gets padded up to full MiB with sufficient room for the GPT
+backup which is stored near the very end of the image file. There is need for
+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.
+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.
+
+   45  46  49  20  50  41  52  54  00  00  01  00  5c  00  00  00
+    E   F   I       P   A   R   T
+   f6  61  10  1c  00  00  00  00  fe  4f  14  00  00  00  00  00
+   01  00  00  00  00  00  00  00  30  00  00  00  00  00  00  00
+   de  4f  14  00  00  00  00  00  73  23  c8  79  19  e6  97  4d
+   95  17  69  30  c5  38  e2  99  de  4f  14  00  00  00  00  00
+   80  00  00  00  80  00  00  00  5b  6b  8a  65 
+
+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
+>>> 512 bytes.
+
+
 ------------------------------------------------------------------------------