Cianer.com

One of my machines runs linux from an SDCard but I want to be able to pull the power without shutting down gracefully.  It struck me that the best way to protect the SDCard was to mount the root filesystem read-only and use unionfs or aufs to merge it with a RAMDisk.  This allows the system to write to /etc/resolv.conf, /etc/mtab, /etc/udev and anything else it needs to alter without bothering the SDCard.

I decided to use aufs for this for one very simple reason:  I found someone else on the internet who had already done it.  I needed to make some changes from his method so I'm reproducing it here, but all credit goes to the author of that post.  The main change I made from his version is that I removed the modprobe as (a) the -Q flag was causing problems and (b) I'm running Ubuntu 9.10 which uses kernel 2.6.31-14-generic, so aufs is already in the kernel.

My mate Mark Ryan was recently burgled and the thieves made off with all his computer equipment, however in a stroke of pure luck he had brought his backup drive into work that morning so he didn't lose his family photos.  This got me thinking - my incremental backups are a great idea, but since the primary drive and backup drive are both attached to the same machine I risk losing everything I am the victim of a robbery/house fire/whatever.  It might seem like macabre paranoia but if anything like that happens its not the equipment you'll miss - its the photos of your wedding day and your kids growing up etc. etc.  For most people an online backup would be the ideal option here, but my wife is a keen amateur photographer so at time of writing we have 29GB of photos (and increasing rapidly) and a crappy 128kb uplink so this is not feasible.

Happily we do have a log cabin down the end of the garden with electricity and network connectivity in it, so I set up a second backup machine down there using an old HP desktop from 2001 (who says computers are obsolete after 5 years?).  The network connection to the cabin is Powerline Ethernet over an 84m stretch of cable so the data rate isn't amazing, hence doing an rsync of the 3-months worth of incremental backups would likely take forever.  Instead I did the following:

1. Use rsync to mirror the shared directories on the main server to the secondary server in the cabin
2. Run rsnapshot locally on the 2nd machine to get the incremental backups

This has the advantage of allowing me to export the shared directories using samba, so the secondary machine is ready to step into the breach immediately should anything happen to the primary one.

World of Goo is a fantastic game so when I decommissioned my old Windows XP Pro laptop I wanted to move the savegame to the new Ubuntu laptop.  I didn't want to have to deal with Fisty's Bog again if I could avoid it.  Unfortunately the World of Goo save file, pers2.dat, was not where their F.A.Q. said it would be.  It didn't show up in an initial search of the hard disk either, which was weird.  I included hidden files in the search and it showed up in C:\Documents and Settings\%userprofile%\Local Settings\Application Data\2DBoy\WorldOfGoo\

Copied it to ~/.WorldOfGoo/pers2.dat in Linux & all was tickety-boo.  So basically if you are having trouble finding it enable "search hidden files & folders" in the advanced options of Windows search.

Update:  Someone already posted this on the World of Goo forum.

I have a samba share on our backup machine to allow access to Photos/Movies/Music etc from windows machines.  To save me having multiple shares I created a symlink from the samba-shared directory to my home directory so I could access it from windows machines etc.  This worked perfectly until a recent Ubuntu upgrade broke it (on purpose).  See Samba Bug 7014 or Ubuntu bug 542005 for details.

To cut a long story short I followed the advice of my mate Tom and instead of using a symlink I mounted my home directory as loopback inside the samba-shared directory, and Bob's your uncle.  /etc/fstab now looks like this:

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=8abe9e38-a3d6-44c5-a17a-431f89cbb1a3 /               ext3    errors=remount-ro 0       1
# /home was on /dev/sda3 during installation
UUID=fcdf535f-c39d-45d1-b224-1b0a17c068b4 /home           ext4    defaults        0       2
# swap was on /dev/sda5 during installation
UUID=e4acdc1a-d483-4f24-9ef1-a85eb947ffc8 none            swap    sw              0       0
# Main drive for samba shared files & backups (external USB 1TB MyBook Drive)
UUID=6a7afc64-59bc-42f1-a8d8-6c5511eaf673 /media/1TBMyBook  auto   defaults,users,auto  0       1

/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

# Mount some directories loopback inside the samba shared directory so we can
# access them via samba (fix for Samba bug 7104 requires this)
/home/cianer    /media/1TBMyBook/shared/cianer  none    bind    0       0

Tom not only suggested this workaround but also found the correct fstab parameters for me, so I should leave the parting words to him: