Archive for May 4th, 2006

I made a mistake when I set up my MacBook Pro. Namely, I elected to have a single boot partition of 30GB with the remainder being home to my user account. Stupid me. I need to fairly regularly have two different boot configurations; one stock, software update only, partition and one partition that can be futzed with at will.

What a perfect time to use 10.4.6’s resizeVolume to make myself a new boot partition.

Don’t even think of doing this without making a backup or five first. I saved a disk image of the entire drive prior to doing this. And I ran BackUp to another device. And I also updated 3 separate Aperture vaults. And I also copied the contents of the drive to another machine, too. No, I’m not kidding — what follows can seriously hose your data. Heck, I may have actually created an overlapping partition map and my “success” may actually be “slow data rot”.

Update: One bit of subltety. Apparently, a bootable partition needs to be evenly divisible by 4,096 bytes. That explains the small slice between partitions 2 and 3 seen below. I didn’t do that for partition 4 and spent a bit of time figuring out how to resize the partition properly. More details later.

Sure… first to check to see what I have available:

% sudo diskutil resizeVolume disk0s3 limits
For device disk0s3 Data:
        Current size:   63244640256 bytes
        Minimum size:   33682370560 bytes
        Maximum size:   63244640256 bytes

So, in theory, I have about 30GB or so that I can rip out of Data for use as a boot volume. I do want some buffer space, so I’ll go for 20GB or so.

That would be a command something like the following (to create a 20G partition named MunchyTown):

sudo diskutil resizeVolume disk0s3 40G "Journaled HFS+" 20G MunchyTown

Crunch…crunch…crunch… about 5 to 10 minutes later, the command fails stating that the Data volume ran out of space. More likely than not, this means that the minimum size is an absolute minimum assuming that all files could be packed into the partition without any fragmentation. That simply isn’t possible and, as such, the actual minimum will be some other number.

Given the time it takes to do this operation, I figured I could short cut a bit by resizing the Data partition down only a little bit and then resize the MunchyTown partition later. So:

sudo diskutil resizeVolume disk0s3 50G "Journaled HFS+" 1G MunchyTown

OK — that worked and I managed to get my data partition down to 44G. But it didn’t quite do what I expected. Namely, I now had free space interleaved with the Data and MunchyTown partitions. Quite literally: [OriginalBoot][Data][FreeSpace][MunchyTown][FreeSpace].

Well, crap. Now what? resizeVolume doesn’t seem to allow one to reclaim space before the partition being resized. Or something. In any case, this was not looking good. Poking with diskutil quickly led to the conclusion that the only way to fix this is to edit the partition table of the drive.

So, tossing the machine into FireWire target mode and connecting it to my wife’s powerbook, I fired up the gpt utility and started poking around. First, I had to figure out the existing partition table. It looked something like:

% sudo gpt -r show /dev/disk1
Password:
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640   62652416      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   63062056     262144
   63324200   92274688      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  #########   ########
  #########   ########      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  #########   ########
  195371535         32         Sec GPT table
  195371567          1         Sec GPT header

The “######### ########”s are just because I didn’t write down the values. As can plainly be seen, partition 4 is sitting smack between 2 chunks of unallocated space (I have no idea why there is a small space between 2 and 3 Update: I do now! That is a little bit of padding that allows partition 2 and 3 to be a size in bytes that is divisible by 4,096!).

gpt can delete that (you can add -r after ‘gpt’ to make it do a read only operation):

sudo gpt remove -i 4 /dev/disk0

To see the results:

% sudo gpt -r show /dev/disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640   62652416      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   63062056     262144
   63324200   92274688      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  155598888   39772647
  195371535         32         Sec GPT table
  195371567          1         Sec GPT header

Excellent! Now, to add an hfs partition (and verify):

% sudo gpt add -b 155598888 -s 39772647 -t hfs /dev/disk0
% sudo gpt -r show /dev/disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640   62652416      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   63062056     262144
   63324200   92274688      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  155598888   39772647      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  195371535         32         Sec GPT table
  195371567          1         Sec GPT header

From this point, it was a simple matter of rebooting the machine and using Disk Utility to format the freshly created partition. While there was a couple of moments of “Oh Crap! What have I done!” in between, I ended up with a 44G Data partition and a 19G munchable boot volume — just about perfect for my needs.

Except it wasn’t perfect. I couldn’t install onto the new partition because Installer complained about not being able to make it bootable. A bit of research finally revealed that the problem is that the partition I was trying to install into did was not of a length evenly divisible by 4,096 bytes. OK. Whatever. Disks are weird. 4k is, likely not coincidentally, the same size as a Mac OS X memory page. I would expect that the disk is likely subdivided by 4K clusters or something. I’m curious, but would rather have a working boot partition.

So, time for a bit of math. Partition 2 is my original 30GB boot partition. Yet, it is listed as having length of 62,652,416 — clearly, not bytes. The drive is subdivided into sectors and they happen to be 512 bytes, yielding 32,078,036,992 bytes — 30GB.

So… how many sectors do I need to subtract from 39,772,647 to yield some multiple of 4,096 bytes?

Uhhh… damnit. Still don’t need calculus, but that elementary math is about to come in handy. Or I could be über-lazy and just let the system do it for me. Actually, it isn’t lazy, it is just letting the system do the number crunching for me.

First, I deleted the partition using sudo gpt remove -i 4 /dev/disk0. Then I recreated the partition quite a bit smaller than desired using sudo gpt add -b 155598888 -s 39760000 -t hfs /dev/disk0 (39760000 sectors yields 20357120000 bytes, which is evenly divisible into 4970000 4096 byte chunks).

From there, it is a simple matter of using sudo diskutil resizeVolume disk0s4 limits, followed by sudo diskutil resizeVolume disk0s4 XXXXXM to specify a size in megabytes where XXXXX is the max size returned by limits divided by (1024 * 1024) — thus yielding a size guaranteed to be divisible by 4,096.

Done and done. The damned thing boots now. Woot! I would post more specific details — numbers and all — but I didn’t have time to do more than make this work now, damnit! this afternoon.