Feb<-- Mar 2024 -->Apr
S M T W T F S
25 26 27 28 29 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31 1 2 3 4 5 6

Disclaimer: The entries you find in these pages are based on my individual opinions and thoughts. Some of the entries may be just plain wrong, and others harmful. Should you choose to act on, or try, anything you find on this site, you assume any and all risks associated with your actions. So there.



 


Repartitioning to Upgrade

March 11, 2008

Recently I have had to do several Mac OS X system upgrades (to Leopard) where the hard drive had to be repartitioned first. The previous system administrator had partitioned the drives into three parts: one for system and apps, one for data, and one for archive. He must not have realized that the Users home folder would be on the System Partition, and would slowly grow, or he would have given this partition the largest share. The upshot was that these systems had only about 3Gb of available space on the system partition.

The big problem was that these drives had more data than would fit on my 100Gb portable drive -- the one I use for this kind of thing. The client had a server, though, so I decided to use this to backup the hard drives. My plan was to create a disk image of each of the three partitions, then restore the primary image back to a single partition on the drive, verify that it was bootable, then perform the upgrade on the newly expanded drive. As an aside, you might think that backing up over the network would be slower than using an external drive. Nope. This network was gigabit ethernet, and it was actually faster.

I ran into trouble right away. While the Leopard Installer DVD allows you to browse the network, it will not allow you to authenticate to a resource. So, I had to setup a public folder on the server that was accessible to guests. Then I used Disk Utility to make a Disk Image of each partition, and saved it into the public folder.

The next problem I ran into came when I went to restore the system disk image to the newly partitioned hard drive. Disk Utility gave me the error "Restore Failure: Could not find any scan information. The source image needs to be imagescanned/scanned for restore." My heart sunk because I though the disk image was somehow corrupt. The fix, however, was simple. I poked around the menus in Disk Utility, and under Images was "Scan Image for Restore..." Thinking that it couldn't be that easy, I gave it a shot, chose the disk image, and bingo, it appeared in the left column, ready to be restored.

After that, the install went flawlessly -- well, almost. See my next post.

Leopard iCal Publishing Bug

March 11, 2008

Apple Discussion

If you have an iCal calendar published to A Private Server (webDAV), AND you have a .Mac account, you may find that your calendar stops publishing to the webDAV server, and starts publishing to your .Mac account.

What is worse, if you DO NOT have a .Mac account, but you DO have the .Mac account info filled-out (say, you used the trial and let it expire), this can happen too you as well. Only, in this event, the calendar will no longer be published anywhere, since .Mac won't accept invalid credentials.

I discovered this at a client's office where, literally years ago, everyone signed up for trial .Mac accounts. They found it not to be useful, and so let everything expire. Due to the very wonderful Migration Assistant, all of that account info has moved forward throughout the years.

Last year we installed an Xserve and have used it ever since as a webDAV iCal server. After upgrading everyone to Leopard last month, many people's calendars stopped updating. The common thread has been that every one of the problem calendars suddenly showed that they were being published to .Mac. Those clients where, at some point, I had gone in and cleared out their .Mac into, were not affected.