I dist-upgraded my Intrepid machine to Jaunty a couple of days ago. I thought it might break something, boy was that an understatement. As is usual on dist-upgrades for me (Debian and Ubuntu, for the past 5 years or so), the upgrade doesn’t complete the first time it is run. It runs into dependency issues. Running it multiple times consecutively resolves them (must be some race conditions, sigh). Oh I should mention the ONLY reason I was performing the upgrade is that I wanted access to OpenOffice 3. It’s been out since the beginning of the year, but Ubuntu have only just added it into their distribution. It’s MUCH better than 2.4.2, and I’d been running it from the binary distribution that I’d downloaded. There were no problems working inside OO3 from the binary distribution, the problem is, nothing knows that it exists. The install paths for the binary are quite different to Debian’s (and thus Ubuntu’s) and Firefox refuses to acknoledge it as a possible application for anything, and the Thunar file manager conveniently never remembers it’s location when I “open with”. It was driving me nuts.
So after the first dist-upgrade, my X-server broke. Now, that was kind of expected as I’m using a proprietary ATI driver. But that wasn’t what broke. What broke is that my mouse no longer functioned in X. GDM would start, and I just couldn’t move the mouse. I thought it might be related to the partial upgrade, so I run the dist-upgrade again, and also restarted for good measures. The result? The computer failed to boot. It seems that in the current stable version of the Kernel for Ubuntu, 2.6.24, there is a bug with some chipsets that causes the SATA drives not to be recognised. Thus, there is no drive for the kernel to boot from. Now, dist-upgrade is not intelligent to realise that the kernel is a core piece of software and perhaps that old kernel boot image should be kept and marked as “old” (as with what happens when you follow the kernel.org instructions for the source), so I was left with an unbootable system.
With the help of a rescue CD and chroot, I upgraded to the unstable kernel, 2.6.28, and it picked up the chipset properly again, and booted. However, the X problem remained. I fiddled with the X configuration, moved my mouse to a different port, no avail. Eventually I decided to just upgrade the xserver-xorg package and the corresponding x packages to ensure that they installed correctly. At first I couldn’t do this because the installation of the unstable kernel does not automatically install the kernel modules packages, and so I had no ethernet. I had to do the rescue CD + chroot trick to install the linux-modules-2.6.28-11-ubuntu package. After this, I still had no ethernet. For some reason it was not autoprobing my ethernet device deiver. Grr. I eventually also found out that my ethernet device, the Attansic / Atheros L1 is under the Firewire bus. I have NO idea why. Inserting the firewire module results in the ethernet driver loading up straight away. Eventually I just added the ethernet device module, atl1, to the /etc/modules.conf to force the system to load it at startup. Phew, at least it worked, now I could update X!
The result? Now when I start the XServer, it crashes immediately. Not the XServer, the whole computer. I get funny images on my monitor, as if it used the graphics card incorrectly, and then it crashes immediately.
So I finally made the decision to switch to FreeBSD as a desktop operating system. I lose the ability to run VMWare but that’s about it. I chose PC-BSD because it has commercial support, which I thought would make it more stable and configuration-friendly (it does). In order to get the OS installed, I booted off the XUbuntu 8 live CD that I had and used GParted to remove my old Linux partitions and combine them into a big partition for the new OS. I left the data partition (a 160G partition containing my data, always nice to keep the OS and the user data separate). When PC-BSD installed, I didn’t notice the parition size didn’t match up to what I’d just created. The result? PC-BSD thought that it was on the whole area of the disk; the parition pointers were all wrong. I guess GParted broke something. I should have just used fdisk :/
Now, I managed to get this fixed, with Acronis tools and a reinstall of PC-BSD. I got everything sweet and began to unpack some archived data off the data parition. It failed, crashed the computer, and reset the power. Upon reboot, PC-BSD wouldn’t mount the ext3 partition anymore; it complained of a bad superblock. I’ve had this before, it usually just means the drive needs and FSCK because something went wrong in writing to it. I booted back into the XUbuntu live CD, ran FSCK and hey presto, MANY illegal block errors. I left it running for about 6 hours (fsck -y) and came back to find that it had removed all files, and recovered about 60G of the 160G in the lost+found directory. My best guess is that GParted screwed the partition pointers up, then PC-BSD wrote to some wrong areas of the parition so that when it mounted the ext3 data patition, the inodes were broken, and the FreeBSD implementation of the code for ext3 couldn’t cope with it and made the problem worse. I’m still recovering my data, and I realise I have lost about half of it. It’s ok, because it was mainly used as a buffer drive, but I don’t have a full list of what is gone which is annoying. I don’t think I’ll be going back to Linux for a while. In BSD they are quite good at making sure applications are quite stable before putting them into the ports area (much better in my experience, and faster - they had OO3 ages ago!!).