[Up] [Map] [Eryk's home page] (Feedback)

Are you sure you want to know this?

A bootable CD is on that can be the boot disk for a MacOS system. This page is about how a bootable CD works rather than how to make one.

The first thing I recommend, if you really want to know details, is to read "Technote 1189: The Monster Disk Drive Technote" from Apple Tech support. While the main audience is device driver writers it has an excelent bibliography (essential when it comes to Apple documentation) and contains a great deal of arcane information useful to people like me who write disk partitioners.

Apple wants all devices to pretend to have 512 byte blocks. Can't have an HFS filesystem unless it does so. This is implemented by the driver converting everything from 512-byte sized blocks into whatever the device size is. So for CDs the driver converts to and from 2048-byte blocks. The first apple CDs actually had firmware that did this. You sent a special message to the drive and it put itself into 512-byte block mode. (Of course, if the SCSI bus got reset you had to tell it again, since it forgot.)

There are two partition maps. The first is laid down on the 512-byte blocks. The second is laid down on the 2048-byte blocks. Like so:

512     0  1  2  3  4  5  6  7  8  9 10 11 12
2048    0           1           2           3
That is, the 2K map uses the first 512 bytes of each 2048 byte block. Of course, these maps overlap and that causes some problems. Many CDs have partition maps that are strictly speaking incorrect, but because no one checks it isn't a problem.

The partition map occupies the first N blocks of the disk, but each entry takes only the first 512 bytes out of each block. So while a map laid down in 512-byte block mode will have data in every block, when we view it in 2k mode we will see only the first 512-bytes of each block and thus see the data from the blocks that were numbered 0, 4, 8, 12, etc. in the 512-byte block view.

When viewed as a 2k device a CD has a sequence of blocks numbered 0, 1, 2, etc. each containing 2048 bytes of data. When viewed as a 512-byte device it consists of four times as many blocks again numbered 0, 1, 2, etc., but blocks 0-3 are the data from block 0 of the 2k view, blocks 4-7 are the data from block 1 of the 2k view and so on.

During boot, when block 0 is picked up to get the driver descriptor map, the 2k block map is used to find the entries for the drivers (used to get checksums and what not), the drivers are loaded and start presenting the 512-byte block view, then the 512-byte block map is used to find the HFS partition(s).

It is ugly, but it works - definitely a hack.

You can view the 2K map in pdisk by using the 'E' command and telling it the logical block size is 2048 bytes.

As a final example here is my "Mac OS X Install Disk 1" (v10.2.3). First, in the 512-byte view. (You can tell I did this on OS X because the disk is called 'rdisk1s1'.)

Partition map (with 512 byte blocks) on '/dev/rdisk1s1'
 #:                type name             length   base    ( size )
 1: Apple_partition_map Apple                63 @ 1      
 2:      Apple_Driver43*Macintosh            56 @ 64     
 3:   Apple_Driver43_CD*Macintosh           140 @ 120    
 4:          Apple_Void                       0 @ 0      
 5:  Apple_Driver_ATAPI*Macintosh            56 @ 260    
 6:  Apple_Driver_ATAPI*Macintosh           140 @ 316    
 7:       Apple_Patches Patch Partition     512 @ 456    
 8:          Apple_Void                       0 @ 0      
 9:           Apple_HFS "Mac_OS_X_CD"   1324080 @ 968     (646.5M)
10:          Apple_Free                       8 @ 1325048

Device block size=2048, Number of Blocks=331264 (647.0M)
DeviceType=0x1, DeviceId=0x1
Drivers-
1:   5 @ 16, (20@64)  type=0x1
2:  25 @ 30, (100@120)  type=0xffff
3:   5 @ 65, (20@260)  type=0x701
4:  31 @ 79, (124@316)  type=0xf8ff

Now, in 2048-byte view. Note the 'Apple_Void' partitions, which are a recent hack expressly for CDs. Note the partition_map size: (15 + 1) * 4 = 63 + 1. That is, the size of the partition_map plus the size of block zero has to be equal between the two views. Or you can think of it by remembering block 0 in the 2048 view takes blocks 0 through 3 in the 512 view, so three 512-byte blocks that are in the partition map in the 512 view aren't in the partition map in the 2048 view. That is, (63 - 3) / 4 = 15.

Partition map (with 2048 byte blocks) on '/dev/rdisk1s1'
 #:                type name            length   base   ( size )
 1:          Apple_Void                      0 @ 0     
 2:          Apple_Void                      0 @ 0     
 3: Apple_partition_map Apple               15 @ 1     
 4:      Apple_Driver43*Macintosh           14 @ 16    
 5:   Apple_Driver43_CD*Macintosh           35 @ 30    
 6:  Apple_Driver_ATAPI*Macintosh           14 @ 65    
 7:  Apple_Driver_ATAPI*Macintosh           35 @ 79    
 8:       Apple_Patches Patch Partition    128 @ 114   
 9:           Apple_HFS "Mac_OS_X_CD"   331020 @ 242    (646.5M)
10:                                          0 @ 0     

Device block size=2048, Number of Blocks=331264 (647.0M)
DeviceType=0x1, DeviceId=0x1
Drivers-
1:   5 @ 16, type=0x1
2:  25 @ 30, type=0xffff
3:   5 @ 65, type=0x701
4:  31 @ 79, type=0xf8ff

Thanks to Abe Skolnik for asking enough questions via email that I ended up writing this.


Last Updated: 2003-04-09