It is definitely Iris season. I took a walk in the neighborhood with camera in hand and the intent to take a few shots of every different kind of Iris I could find. The blooms are just stunning this year. I created a flickr set and, of course, the implied Flickr slide show.
Today, I sat down for my morning browse only to find that the AirPort base station was scrolling the rather ominous “Looking for PPPoE Host…” message.
Ominous why? Because if a reboot doesn’t clear the problem, then I have to:
Now, to be fair, SBC’s customer support has always been quite helpful. Once you get to a human. The voice menu system, on the other hand, is a totally nightmarish pain in the ass.
Today, I discovered yet more pain. When it asks “Are you using Windows or Macintosh…?” and you answer with a disgusted “No” after the word “Windows”, you get bounced to the Windows tech support line.
I spoke with a very nice woman in the Indian sub-continent who insisted that I had to be bounced to Macintosh tech support regardless of the fact that it is the modem that is failing to connect. Damned tech support scripts.
Then it was off to several minutes in the droning “Please Wait” every 10 seconds purgatory. Interestingly, once connected to the Mac service center, the individual on the end of the line sounded like a native English speaker and indicated that she was in CST (maybe). Odd. I wonder what cost analysis led to such a subdivision in the call centers.
In any case, this entire exercise yielded nothing more than an indication that there is a mysterious outage in the area and that I should call an 800 number to check on case ID #7819. Supposedly, everything will be back online sometime prior to 4:30pm.
In other words, if the DSL modem shows that the failure is above the physical layer then don’t bother calling customer support…
Actually, total black whole. Estimate up time: 2 hrs. 5 hrs. 5 hrs. Now down for 24….
Andrew Stone is in town for the weekend and I had a chance to play with his new app.
It is quite incredibly cool. Andy has the knack for taking Mac OS X media APIs and making ‘em do quite totally surprising things…
I’m having a lot of fun stewing my photos and music into new stuff.
We are having a small Stone Gathering today and I’m smoking a turkey (pictured at the left; basted, sitting on a beer can and ready to head into the BGE). I have never cooked a turkey before, so this should be an adventure.
The turkey is sitting on a Fosters beer that is about 2/3rds full of beer with the rest of the space occupied by garlic, onion, and dried scotch bonnet peppers. The turkey was brined in apple cider, water, salt, honey, maple syrup, and black pepper. Prior to putting it on the BGE, I created a basting sauce containing honey, molasses, budapest paprika, oil, apple cider, rosemary, finely ground coffee, salt, pepper, and fresh orange. This was ground into a liquidy paste that was slathered on the turkey.
The turkey will cook for about an hour at 250 degrees and then I’ll boost the temperature to about 300 for the next few hours, followed by a finish at 350 to 375.
It is being smoked over a mixture of fresh apricot wood and hickory chips on a bed of mesquite charcoal.
The second photo is from about half way through cooking. Normally, you never open the egg during cooking. Given the long cooking time and the yumminess of the basting goop, we decided to crack the egg long enough to add another coat of goop. Smells damned good.
Was damned good. And, No, I do not drink Fosters. It just happens to be in the perfect can to shove up the hind end of a turkey. There is nothing else holding that bird up right other than the can and the two legs.
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.
Apple has surpassed Dell in the market cap department. This happened earlier in the year and then Apple’s stock got nailed.
Hopefully, that won’t be the pattern this time around.
Ronald Oussoren — of PyObjC and Universal Python fame (amongst other things) — is in town and will be joining us for Korean food and Bowling this evening. Korean food starts at 7:30pm at Fusion Korea next to Homestead Lanes (though we don’t bowl there — long story).
![[ Yahoo! Maps ]](http://us.i1.yimg.com/us.yimg.com/i/us/mp/gr/mplogo.gif){kind=small}