Way back in 2004, my parents, like so many other consumers, ditched their old computer and bought a new one, a Systemax Venture with 512MB RAM (if I recall correctly — they upgraded to 2GB some time ago), a 2.5GHz processor, and a 50GB hard drive with a 10GB “recovery partition”.  In the five years that they’ve had it, I’ve been their tech support — which is probably the reason it’s lasted five years in the first place.  Those same five years were when I started growing excessively curious about computers, so it’s taken its share of poking and prodding (though probably not as much as my own machine, which ultimately got its drive split into several partitions and linux installed on it ).

After so much “experimentation”, it recently seemed to have given up.  It came down with a case of constant rebooting, a very common issue which happens when XP’s “automatic reboot-on-error” feature is enabled, and it throws fatal errors constantly.  What happens is an error is thrown, so it reboots.  But, of course, nothing was done to correct the error, so it is thrown again, causing a reboot.  Normally, we could get 15 minutes of uncertain “working state”, before the thing would either lock up (followed by us pressing the power button) or reboot itself, and that was when we were lucky.

A temporary fix that I found was to perform manual system restores on the hard drive, which involved hooking the drive up to another computer, going into the filesystem, and moving system files around.  It worked the first few times, but the main problem always came back after a while.

There were a couple of times when I suspected it might be an overheating problem.  I would boot into the bios and pull up the “PC Health Status” screen, which gave fan speeds and CPU temperature, and wait for it to lock up again.  I believe there was one time the temperature got above 200 degrees Fahrenheit, even.  With this revelation, we replaced the fan.  The replacement worked well, but, inevitably, other problems developed.

It started its constant reboot syndrome again, but this time even system restores wouldn’t work.  It got to the point where it was unusable, so in leu of unstable Windows, I burnt and booted an Ubuntu livecd.  Since there was hardly extra space on the original HD, they just ran off the livecd.  That worked for a while, allowing them the basic necessities of the internet (they had already been using FireFox at that point) and document editing (which documents they saved to a flash drive), until even Ubuntu started kernel-panicing, seemingly spontaneously.

It was at this point that they were ready to buy a new computer.  Not because they wanted a new computer.  Because they were sick of the old one not working, the common “excuse” to buy a new computer .

What about the “recovery partition”, you ask?  After all, surely the OEM put it there for a reason?  Well, I had come into posession of an older 60GB hard drive, and then I discovered dd, a linux “block copying” program.  Long before the machine became unusable, I used dd to clone the original 50GB drive to the 60GB drive, and ran the recovery program, just to see how it worked.  After the recovery program did its thing, I was asked to reboot.  Upon reboot … the OS wouldn’t boot.  Period.  Can you blame me for not wanting to try that on the <i>original</i> hard drive?

Fortunately, about December of 2007, I had discovered — and experimented with — partimage, a linux-based partition imager.  I had made backups of a few partitions from a few computers, and stored them on my external 500GB hard drive for future reference.  As luck would have it, one of those partitions was the main 40GB partition from this computer.  You can imagine my hope, curiosity, and anticipation when I (re)discovered this.

I promptly made two backups of the 40GB main partition on the drive — one partimage backup, and a complete file system copy to a folder on the external drive — and began the process of restoring the partition to its December 2007 state.

The restore was successful.  The computer booted fine, and here nearly a week later it still works great.  No more constant reboots.  There were a few minor issues — like account settings that were lost, and the fact that it had reverted to a pre-SP2 state — but the filesystem copy I had made contained any files they might want to retrieve.

The moral of this success story is the same as the moral of any “backup horror story” — backup, backup, backup!  You never know when you’ll lose data, your system will become unusable, or <a href=”http://lifehacker.com/5122848/hard-lessons-in-the-importance-of-backups-journalspace-wiped-out#viewcomments”>a paranoid employee will wipe all your hard drives clean</a>.  You just can’t know.

The horror part?  Well, my parents are still using Windows XP on that five-year-old computer.  I wasn’t quite able to convince them to use Ubuntu for everything .  Oh, well…

The latest version in the Ubuntu Hardy repos is version 1.1.15-1. I’ve been having problems with this version when trying to list increments over SSH; it would, consistently, exit with a “No such file or directory” error whenever I tried to “rdiff-backup -l server::/path/to/backup”. I couldn’t find any info on this problem on the net, let alone a solution. I did, however, find a mailing list entry announcing the release of rdiff-backup 1.1.16. After further googling, I found some rdiff-backup 1.1.16 deb files for Ubuntu Hardy. Download, install on all computers that use it, and, voila, I can list increments remotely!

With the release of Hardy Heron, many X/K/Ubuntu users will upgrade to the new version. Many already have. While an actual upgrade is possible, my preferred method of “upgrading” is through a fresh install. This resets everything to “factory settings”, as it were, getting rid of any junk left lying around from your various tweakings. A fresh start, so to speak. But what about your already carefully-crafted desktop experience? In my experience, I’ve found that there are a number of things you can do to maintain your desktop through a fresh install.

The main thing you’ll want to do is create a /home partition. PsychoCats has an excellent guide on moving your existing home directory. On my system (60GB hard drive), I have allocated about 5GB to my root ( / ) partition, various small amounts to a couple of other partitions, and the rest to my /home partition. Currently (using Kubuntu Gutsy and after installing/uninstalling several programs), I use about 4GB of that 5GB. The benefits of a separate /home partition is that, since all your personal settings and files are stored there, you can safely leave that data untouched during the install.

The next thing to do is to backup all your system-wide settings. This includes your wallpapers (if you’re into that sorta thing), sources.list, xorg.conf, fstab, and possibly your grub menu.lst. These are the main things that normally need reconfigured after a fresh install. You can create a new directory on your desktop (which won’t be erased if you have a separate partition for it), and put all the backups in there, so they’re easy to get to when you’re ready to restore them.

If you’re into collecting wallpapers, you’ll likely want to backup your collection. Whenever I switch to a new wallpaper, I first put it in /usr/share/wallpapers. If you do the same, you can simply copy this folder to the new folder on your desktop. For the rest of the backups, just copy /etc/apt/sources.list, /etc/X11/xorg.conf, /etc/fstab, and /boot/grub/menu.lst to the folder on your desktop. You can use the folowing commands to do it all relatively quickly:

$ cd ~/Desktop/
$ mkdir backups
$ cp -r /usr/share/wallpapers /etc/apt/sources.list /etc/X11/xorg.conf /etc/fstab /boot/grub/menu.lst ~/Desktop/backups/

A quick explanation of the files to backup: the sources.list tells apt-get where to search for available software. I use several programs which are not in the official Ubuntu repos, and this usually involves adding third-party repos to my sources.list file. I like to back this file up so I don’t have to go hunting yet again for the repo info.

The xorg.conf file holds your display settings and other settings relating to on-screen display (such as mouse configuration). Every time I reinstall on my notebook, I have to go in and manually modify the xorg.conf file to enable horizontal scrolling on my synaptics touchpad. Backing up the file allows for quick and easy editing, instead of trying to remember my settings.

Fstab specifies automount details for various partitions. I have two partitions other than my root and home partitions that are setup to automount, as well as several Windows shares that are specified in fstab so as to automate mounting them.

You really only want to backup your grub menu.lst if you have manually modified it for whatever reason (for example, if you have a dedicated grub boot partition). If you normally let Ubuntu auto-config the boot options and don’t touch it afterwards, you probably don’t need or want to back it up.

Install X/K/Ubuntu as normal, specifying your home and root partitions, and ensuring that the installer does NOT format the home partition. You will be required to format the root partition. During the install, you will also want to create any user accounts that you had before, in the same order that you previously created them. User recreation can also be done after you boot into your fresh install, by using the useradd and usermod commands.

After the install, boot into your shiny new installation. Since you’ll need to use root privileges (sudo) to re-integrate your files, you may want to log into a fail-safe desktop. This will give you a command line window, but no window decorations, panels, etc. You won’t need them anyway, yet. To view the contents of files, use the “nano” text editor. Do not simply copy all the files back to their original positions. When a distro is upgraded (or reinstalled), system files have a tendency to get modified (case in point: your sources.list). What you want to do is compare the differences between the old and new files, and make changes as appropriate.

First, move your wallpapers back. You can do this without deleting any new, “official” wallpapers by running the command

$ sudo cp -r ~/Desktop/backups/wallpapers/* /usr/share/wallpapers/

For the sources.list…well…I don’t know of any good way to check for updated repos, other than to change the “gutsy” to “hardy” for each repo line, and run “apt-get update”. If the repo doesn’t exist, you’ll get some output like:

Ign http://repo.freecreations.info hardy Release.gpg
Ign http://repo.freecreations.info hardy/freeverse Translation-en_US
Ign http://repo.freecreations.info hardy Release
Ign http://repo.freecreations.info hardy/freeverse Packages
Err http://repo.freecreations.info hardy/freeverse Packages
  404 Not Found

From there, you could try to pull software from your previously-used gutsy repos, but I really have no clue how stable that would be

Moving on to xorg.conf. Simply look into your backup file, find out the settings you want, and add those to the appropriate places in the new xorg.conf. You will need to use sudo to edit /etc/X11/xorg.conf with root privileges. The same goes for your grub menu.lst.

For fstab, unless you made some change to your partitions between backing up and reinstalling, you should be able to simply “sudo cp” your old fstab over your new fstab. Of course, you should backup the new fstab, just to be safe, and compare all the numbers afterwards to make sure everything will work after your next reboot.

Now that you’ve restored all your settings, you should be able to reboot, log into your normal session, and enjoy your familiar desktop experience under the new distro. After reinstalling all your software, of course

If you find any part of this guide to be lacking in detail, first use Google, secondly email me at andrew at techknack.net or post in the comments. As of this post, I have not, myself, upgraded to Hardy, but I did use this very method to upgrade from Feisty to Gutsy, and I believe this process to still be good for the current distros.

Backing up a Thunderbird or Firefox profile is important, too. Especially if you’re like me, and it would take hours to get Firefox just perfect again after having your profile wiped (if, for example, the drive it was sitting on were to fall to minor corruption). Hunting down that perfect theme (what was it called again?), rounding up all those can’t-live-without extensions…

Under Windows

Under Windows XP (and presumably Vista as well), the default profile for Firefox is found under C:\Documents and Settings\<user>\Application Data\Mozilla\Firefox\Profiles\XXXXXX.default, where that last XXXXX is a random string of numbers. Thunderbird’s profile is located under C:\Documents and Settings\<user>\Application Data\Thunderbird\Profiles\XXXXXX.default. If you’ve used “firefox -ProfileManager” or “thunderbird -ProfileManager” to change your profiles around, these will be different.

Under X/K/Ubuntu

Under Kubuntu (and presumably most or all flavors of linux), Firefox’s default profile is under ~/.mozilla/firefox/XXXXXX.Default User. For Thunderbird, it’s ~/.mozilla-thunderbird/XXXXXXX.Default User.

Methods of backup

A quick google search can turn up lots of methods of backup, including MozBackup. While I haven’t used this extension myself, I’ve no doubt that it works to some extent (or else it wouldn’t have lasted as long as it has). If you prefer GUI solutions, by all means, try it out.

My preferred method, however, is to make a .7z archive of my profile directory (make sure TBird or FireFox is shut down before you zip the archive, though!) This essentially takes a snapshot of the program (including extensions, skins, even open tabs and windows if the “Show my windows and tabs from last time” option is set!); if your profile ever gets corrupted, you can simply unzip the “saved profile” over the current profile, restoring it to the “last known good configuration”, to quote windows.

Another advantage to the zip-it-up method is that you can create “holes” in the profile. For example, with the “Show my windows and tabs from last time” option set, Firefox will leave a sessionstore.js file inside the profile directory; the next time Firefox opens, it reads this file and re-opens all your tabs from last session. Deleting this file from the zip archive creates a profile hole that the more up-to-date sessionstore.js can fit into. Very handy at times.