Thursday, May 24, 2007

Ubuntu 7.04 & a Dell E1505

Ok, so I've had my laptop for almost 6 months now, and had Ubuntu running happily on it for most of those. I'm intending to put together a detailed article with the hardware specs, and all the little tricks I had to follow to get things working properly, but haven't made a lot of progress. However, I still intend to, since I haven't found them collected together in one place anywhere else.

So, I started with Ubuntu 6.10 (actually 6.04, but I wiped that and installed 6.10 within a week), and upgraded to 7.04 the first day it was officially out. The upgrade improved several things, and made several others worse. I've also got a few annoyances and the like hanging around from 6.10 that probably wouldn't be present if I did a fresh install, but I've got the system so heavily tweaked that I'm highly resistant to the idea.

I'll go into more detail later, but for this post I wanted to highlight an issue that showed up yesterday and that I just got fixed, hopefully. Hibernating & suspending have mostly worked out of the box for me, without any tweaking in 6.10. I'd occasionally have issues where it would refuse to hibernate, with the log just showing that powermanager decided to resume after one of the processors (it's a dual core chip) had shutdown, but before it had written the ram to disk. Depending on the exact timing, this either led to it coming back up and just not suspending, or it would lockup, never finishing suspending or resuming. Other than this, and occasionally resuming with the LCD still off, which I fix by suspending-to-ram, then resuming, it hadn't given me trouble. It worked well enough I normally hibernate, and only actually shutdown or reboot a couple times a month. However, it wasn't quite reliable enough that I'm comfortable just shutting the lid and relying on it to suspend automatically.

The upgrade to 7.04 seemed to have increased the reliability, if anything, with one odd side-effect. Almost every time I'd resume, it would play its little siren sound, and display a popup notification telling me that suspend had failed. Of course, considering I only get the message after a successful resume, I found the message odd, but haven't bothered to investigate it at all.

So, yesterday, the only change I made was to install some updates, which were for vim-tiny, vim-common, and samba. These shouldn't have had any effect at all on suspending. So, I finish up at work, hibernate, and go home. At home, I start it up to check something, and am surprised to find myself at a login screen. I logging, and check the syslog for clues. I don't see the normal saving RAM to disk messages, or the normal resume messages, and in their place is a message I don't remember seeing before, which comes near the end of logging before the startup happens. PM: suspend-to-disk mode set to 'shutdown' Unsure if this is relevant or not, I finish what I am doing, and hibernate again. Sure enough, once I get to work the next night, I'm greeted upon bootup with a login screen. I google for this string, and find some of the source code, and an old message or two about failed hibernations screwing with their swap partitions, but nothing catches my eye.

A while later, I notice that the computer has basically frozen. Now, it didn't catch my attention at first, as launching firefox puts my computer out of commission for about 5 - 10 minutes usually, as it loads the 200 something tabs I had open last time I shut it down. (No, that's not an exaggeration, there are currently 217 tabs spread across 3 windows. There used to be about 3 times that. You should see my list.) However, this time it is much longer lasting, and I notice that according to the system monitor, which is only updating sporadically, there isn't much network activity, and all the cpu time is I/O wait. This isn't typical behavior. I finally switch over to one of the text consoles, login, and check top, since I can't get any response in X. Looking around, I suddenly notice something, there is about 12MB of RAM free, and 0KB of swap space. Oh, that's because there isn't any swap on the system. WTF? No swap? This system has 1GB of RAM, and 2GB of swap. Why do I have no swap? I try to login to a couple more virtual consoles to investigate and get my swap activated, but by this time the system is so sluggish that the logins time out before ever actually prompting me for a password. I hard reboot, and start googling from a work computer in the meantime.

The problem I run into eventually is that my swap is still listed in /etc/fstab, yet if I run swapon -va it says it cannot find that UUID. I find some interesting information in this post, however, their commands don't work for me. I then find a link to a comment for bug #66637 from 10/31/2006, which does the trick. Just remember all these commands need to be run as root, or prefixed with sudo. After a reboot, my swap is loaded properly, and the system successfully resumes from a test hibernation once again.