I have installed a 160GB hard disk in my ancient clamshell iBook that believes all disks are smaller than 128GiB.
No serious problem, as long as I don't let Linux disk tools automatically "fix" the size in the disk map. Mac OS 9/X tools both just set up their partition maps with the max size (128GiB) and pretend the rest does not exist. So, I'm practicing for the LPIC level 2 foofarah to sweeten my resume and fill in some gaps in my skill set. Here's the game I'm on, told by the partition map: Partition map (with 512 byte blocks) on 'wd0' #: type name length base ( size ) 1: Apple_partition_map Apple 63 @ 1 2: Apple_Driver43*Macintosh 56 @ 64 3: Apple_Driver43*Macintosh 56 @ 120 4: Apple_Driver_ATA*Macintosh 56 @ 176 5: Apple_Driver_ATA*Macintosh 56 @ 232 6: Apple_FWDriver Macintosh 512 @ 288 7: Apple_Driver_IOKit Macintosh 512 @ 800 8: Apple_Patches Patch Partition 512 @ 1312 9: Apple_Bootstrap relay 8192 @ 1824 ( 4.0M) 10: Apple_HFS classic 8388608 @ 10016 ( 4.0G) 11: Apple_HFS ten 85899344 @ 8398624 ( 41.0G) 12: Apple_HFS swap 6291456 @ 94297968 ( 3.0G) 13: Apple_HFS share 8388608 @ 100589424 ( 4.0G) 14: Apple_UNIX_SRV2 LeRute 12582912 @ 108978032 ( 6.0G) 15: Apple_UNIX_SRV2 LeviMars 83886080 @ 121560944 ( 40.0G) 16: OpenBSD OpenBSD 62988431 @ 205447024 ( 30.0G) Device block size=512, Number of Blocks=268435455 (128.0G) DeviceType=0x0, DeviceId=0x0 Drivers- 1: 23 @ 64, type=0x1 2: 36 @ 120, type=0xffff 3: 21 @ 176, type=0x701 4: 34 @ 232, type=0xf8ff Mac map entries < 9 are stuff the Mac OS 9/x10.2 tools put in for me. I leave 'em in so I can boot Mac OS 9 (and my kids can play bugdom, etc.). Entry 9 is the relay boot partition Linux PPC distros tend to use, 4MB because that's what the Mac OS X tools did this time. (Fedora 12 would not work with size over 1M on that for some stupid reason I never dug into, but Debian seems to be okay with larger.) Initially formatted as Mac HFS, used obsd's pdisk to mark it Apple_Bootstrap. Entry 10 is Mac OS 9, HFS+. Entry 11 is Mac OS X, HFS+. Entry 12 is swap space for Mac OS 9/X, HFS+. Entry 13 is share space, HFS+. After installing Mac OS 9&X, I used obsd's pdisk to cut the remaining freespace: Entry 14 is for the Linux root and boot, initially Apple_UNIX_SRV2. (I believe in wiggle room.) Entry 15 is for the rest of Linux, will be done LVM, presently marked the same as entry 14, initially Apple_UNIX_SRV2. I plan to use openbsd to format 14 as Linux ext2 and put the debian installer in it. We'll see how that goes, later. Debian or Fedora, the Linux tools try to "fix" Apple's partition map, so I want to avoid using them at the Apple partition map level. (Need to file a bug over there, but I don't quite know what to file, yet.) This left 30G of Apple_Freespace (or whatever that was). If I cut more than 16 entries, Mac OS 9 will refuse to boot (or so my past experience says). But 30G is fairly roomy for obsd, anyway, and I'm thinking I can set the limit with disklabel to access the other 25G or so that the Mac partition map is ignoring. So, rather than cut another partition, I set the type of the last entry to OpenBSD and proceeded to install. Do we know whether the Apple file system throws fits or does strange things if the last partition is not Apple_Free? If this is a bad idea, I guess I'll sacrifice the Mac OS swap partition and let Mac OS swap to its own file space, like Apple intended. Well, so far the Mac stuff is okay, and it boots openbsd okay, and I'm walking through afterboot and I notice that /home thinks it's 79.2GB. Not the 15G that I thought I set it to with disklabel. So I guess I wasn't paying attention to the size and it straddled the freespace boundary to the end of the physical disk. But, wait, 15 + 20 is only 35, and this is almost 80, so that's not what happened, either. The disk label: # /dev/wd0c: type: ESDI disk: ESDI/IDE disk label: Hitachi HTS54161 duid: d787879893dfccbe flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 310101 total sectors: 312581808 boundstart: 205447024 boundend: 268435455 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 2097504 108978048 4.2BSD 2048 16384 1 # / b: 2359728 111075552 swap # none c: 312581808 0 unused d: 4195264 113435296 4.2BSD 2048 16384 1 # /tmp e: 6290944 117630560 4.2BSD 2048 16384 1 # /var f: 4195296 123921504 4.2BSD 2048 16384 1 # /usr g: 2097632 128116800 4.2BSD 2048 16384 1 # /usr/X11R6 h: 9022624 130214432 4.2BSD 2048 16384 1 # /usr/local i: 8388608 10016 HFS j: 85899344 8398624 HFS k: 6291456 94297968 HFS l: 8388608 100589424 HFS m: 3064320 139237056 4.2BSD 2048 16384 1 # /usr/src n: 4195296 142301376 4.2BSD 2048 16384 1 # /usr/obj o: 166085120 146496672 4.2BSD 2048 16384 1 # /home Okay, looking at that carefully, I now see that disklabel grabbed the first Apple_UNIX_SRV2 partition, ignored it's size as if I was deliberately playing games with the Apple partition map (to what purpose?) and gave me the whole rest of the disk to the end. Ouch. Guess I'm going to have to re-do this. But disklabel ignores the Apple map partition boundaries. Would that be safe, were I to decide to forget messing with Debian on this box after all, and refrain from using the Mac OS disk tools, as well? And, if that would be safe, what about the 128G boundary. I'm assuming that the best approach would be to add a partition after the 128G boundary, but is the theoretical end of the disk safe to ignore? -- Joel Rees <joel_r...@sannet.ne.jp>
