Using Rsync to Backup Filevault From Mac to Windows

16 May 2007

Rsync is a great tool that’s been around on unix forever. It lets you synchronize directories locally or over a network, copying only the pieces that have changed.

A neat trick for backing up Mac OS X to Windows is using Windows Sharing. Once you connect to a Windows share, the share shows up on your local filesystem in /Volumes. If your share is named “Backups” it will show up as /Volumes/Backups for instance.

The problem is when you try to use rsync to backup your home directory. If your home directory is encrypted with filevault, rsync will spin and die on the /Users/.username and /Users/.localized files.

I first tried using the –exclude option to rsync to get around these files, but for some reason didn’t have any success. However, backing up the individual /Users directories works fine!

Here is the script I’ve been using. Find the /Volumes directory that your Windows mount is showing up as, and drop it in the script along with your username. The first time you backup, be sure to connect with an ethernet cable. The wireless network is too slow to transfer gigs of data in a reasonable timeframe.


!/bin/bash
SOURCE=/Users/username
DESTINATION=/Volumes/SHARE
MINIMIZE="--modify-window=3"
rsync -auv --delete $MINIMIZE $SOURCE $DESTINATION

Paste this script into a file, say “backup.sh”, and run it with “./backup.sh” at the command line. Make sure your share is mounted or you’ll start backing up your users directory to the same hard drive its already on, and quickly run out of space!

Jeremiah’s AGP Problem

16 May 2007

My friend Jeremiah bought a brand new video card. He put it in, and the computer would no longer display any video. He took it out, put his old card back in…still no video. However, the onboard video still worked. Weird stuff. How could his new video card have broken his ability to use video cards?

Click on this picture to zoom in, and look very closely inside the dude’s head, where his body and mustache would be pointing if they were perhaps originally an arrow before they grew a head, legs, arms, and hair.

Jeremiah’s agp slot

Yep, it’s missing a copper connector! Not only that, but the copper connector was bent down and crammed into the bottom of the agp slot. This is how we noticed it in the first place – the glint of silver in the bottom of the agp slot.

Jeremiah’s copper connector

That little connector means my friend had to replace his motherboard – the least fun component to replace in a computer.

Upgrade to Feisty, Nvidia module wouldn’t load (fixed!)

16 May 2007

I originally posted this on ubuntuforums:
http://ubuntuforums.org/showthread.php?t=419208

I wasted several hours researching and debugging an Nvidia problem preventing the ‘nvidia’ driver from loading. I eventually fixed it, but not having seen the problem listed elsewhere, wanted to share the details here.

On the first reboot after running the upgrade from Edgy Eft, gdm failed to start and gave me a blue screen of death, with the option to view detailed log messages about the failure. There was something in the message about “Incorrect kernel version for nvidia module” (as best I can remember). This was my first clue, but I took it in the wrong direction.

I spent the next couple hours installing, purging, reinstalling, purging, the various Nvidia-glx-new, Nvidia-glx-legacy, and Nvidia-glx modules. It wasn’t until I started trying to compile the downloaded drivers from Nvidia’s site that I finally figured out what was going on.

By chance I ran the command `uname -r` and realized that even though the 2.6.20-15 kernel was installed, my Grub confiuration had not been updated, and was still booting by default into the 2.6.17- kernel. So step 1 was to manually select the 2.6.20-15 kernel boot option in Grub.

This got me back to the original “Incorrect version/API” error message. After some trial and error I found that the nvidia-glx module was compiled against an older kernel or Xorg version. The nvidia-glx driver version is 1.0-9631. After remove-purging nvidia-glx and instead installing nvidia-glx-new, I found this driver, version 1.0-9755, was a match for the version/API that was causing a problem.

So I restarted gdm, and sure enough, my same old Edgy xorg.conf worked fine and X started up with Twinview enabled and everything!

So to summarize…
If X fails to start after upgrading to Feisty Fawn, check what kernel you’re running with `uname -r`. If it’s 2.6.20-15, make sure you’ve got nvidia-glx-new installed, as opposed to nvidia-glx. If you’re not on kernel 2.6.20-15, check your grub configuration or boot options, cause as best I can tell you *should* be on 2.6.20-15 if you’ve upgraded to Feisty.