diff --git a/doc/boot_sectors.txt b/doc/boot_sectors.txt index ae01faf..32c19a2 100644 --- a/doc/boot_sectors.txt +++ b/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 - >>> ??? which is at 332362 (* 4 = 1329448) - >>> ??? 1 MiB alignment ? + | This is 1 KiB before the end of MBR partition 1. + >>> ??? why 1 KiB and not 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 / UUID = { - | | 0x73, 0x23, 0xc8, 0x79, 0x19, 0xe6, 0x97, 0x4d, - | | 0x95, 0x17, 0x69, 0x30, 0xc5, 0x38, 0xe2, 0x99 } + 56 - 71 | guid | Disk GUID + | | Random, produced by uuid_generate(), + | | 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. - -The ISO image has a size of 332362 blocks of 2K = 1329448 blocks of 512. +A GUID consists of a 32-bit integer, two 16-bit integers, and an array of +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 - 16 - 31 | part_guid | Unique partition GUID = random + 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 + | | 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. + + ------------------------------------------------------------------------------