Month: August 2009

I was getting this message:

Mac OS X cannot be installed on “silver”, because this disk cannot be used to start up your computer.

The problem turns out to be that the Mac OS really wants 128MB of unused space after your main Mac OS partition. If your partitions are back to back then you will get this message. The fix seemed like it would be easy. But unfortunately it was not. When I tried using Disk Utility to tweak my partition around it would immediately get the error “MediaKit reports no such partition”. Great. So I booted into the Snow Leopard CD, launched terminal and ran the following command:

$ diskutil list

This let me figure out what my disk partition number and what the new size should be. Here is my output:

/dev/disk0
   #:                       TYPE NAME         SIZE       IDENTIFIER
   0:      GUID_partition_scheme             *500.1 GB   disk0
   1:                        EFI              209.7 MB   disk0s1
   2:                  Apple_HFS silver       452.8 GB   disk0s2
   3:       Microsoft Basic Data              21.7 GB    disk0s3
   4:       Microsoft Basic Data NO NAME      21.5 GB    disk0s4
   5:                 Linux Swap              3.8 GB     disk0s5

So my OS X disk is “silver”. I took 452.8 and subtracted 128MB which is basically .1 and then subtracted another .1 for good measure. Then I ran the disk resizing command like this:

$ diskutil resizevolume /dev/disk0s2 452.6GB

This went through and did an fsck (verified the disk format) and spit cool little text progress bars at me (I’ve never seen a barbershop pole in text before, thanks Apple). When it was finished checking the disk it went ahead and shrunk my partition. Yay for command line tools that actually work!

After resizing my partition the Snow Leopard installer magically decided it was bootable and I was able to install.

My brother had this exact same thing happen to him except his Disk Utility (and even diskutil) told him that there wasn’t enough space on his disk when he tried to resize it. So I had him grab a disk defrag utility and check out the disk. It appears he had some stuff at the end of the disk and we are theorizing that Disk Utility doesn’t move files around in order to shrink the disk. So he started up a defrag process and went to bed while it chugs along. I’ll update later and report whether that fixes his problem or not. I have high hopes though.

Update: His defrag finished and he was able to resize his partition in Disk Utility and after that Snow Leopard let him install.

I got annoyed today when I ls-ed on my Mac OS X 10.5 system and saw this:

drwxr-xr-x@ 3 root  wheel  170 Jun  7 17:35 F9D86DAF-2868-4918-948A-110BB55DAB11

Well, that’s not what got me annoyed. I tried to look up what the ‘@’ after the permissions meant in the man page and it didn’t mention it at all. I searched the web and found someone quote an excerpt of the man page that explained the ‘@’. And it was not in my man page at all! That is when I got annoyed.

Then I remembered an exchange with a commenter: earlier where it seemed like my docs were old.

So I set out to find why my man pages were out of date. After some poking around I discovered this:

$ ls -l /usr/share/man/man1/ls.1*
-r--r--r--    1 root     wheel       15708 Mar  1  2006 /usr/share/man/man1/ls.1
-r--r--r--    1 root     wheel        6220 Apr 20  2008 /usr/share/man/man1/ls.1.gz

So at some point the system installed new, nicely gzipped man pages but somehow failed to remove the old ones. And it turns out the man give the non-gzipped version precedence. Giving me old out of date documentation when I ask for it. Weak.

A quickie perl script seemed in order:

find /usr/share/man -name "*.gz" -or -print \
    | perl -ne 'chomp; print "$_n" if -f "$_.gz" && -M $_ > -M "$_.gz"' \
    | xargsn -n 10 sudo rm

where xargsn is defined in my .bashrc file as:

alias xargsn="tr '\n' '\0' | xargs -0"

Using GNU xargs you can just do xargs -d\\n which is way easier for me to remember but stupid bsd xargs doesn’t appear to have the nice -d option. Weak, but I digress.

Anyway, the script finds non-gzipped files in the system man hierarchy and, if they have an equivalent gzipped version that happens to be newer, deletes them.

I had about 4500 that I was able to delete, and now my ls and chmod man pages have up-to-date info again. Aaaahhhhh.

You might notice that I only deleted the non-gzipped version if it was older. It turns out I had about 10 man pages where the opposite was true. So I tweaked my script a little and did this:

find /usr/share/man -name "*.gz" -or -print \
    | perl -ne 'chomp; print "$_n" if -f "$_.gz" && -M $_ < -M "$_.gz"' \
    | xargsn -n 1 sudo gzip -f

This one gzips the man page and replaces the older gzipped version when they both exist and the gzipped is older.