Kiddo Quote

So, a while back, we had bought the kids a small treat of some kind, a snack size bag of cookies I think. So, on my day at home with them, I gave them each one, then closed the bag and set it down. So, several minutes later, my daughter walks into the room where I was folding some clothes, hands me the bag, and asks if she can have another one.

I pick the bag up, and being looking at the nutritional information on it. She asks me what it says, so I start reading some of it aloud. Things like serving size, calorie count, etc. She gets this very serious, disappointed sound in her voice, and says, "Oh, man."
"What?", I asked, "Do you know what any of that means?"
"It means I won't get any more."

So cute I almost cried.

Bug Affliction

A few weeks ago, I lost my swap space again, exactly like last time. Once again, a resume from hibernate failed after a routine fsck check ran. And once again, I missed the fact that my swap was gone until later when I noticed the computer failing to hibernate due to lack of swap space.

Since this was the second time it happened, I was sure that it wasn't due to an accidental run of mkswap. Not that I was doubting it after the first time, but you wonder if maybe some obscure option you hit in the GUI might have triggered it behind-the-scenes or something. This time, I was certain.

I was also thankful I blogged the instructions for fixing it the first time, as it save me a lot of research this go-round. Not that I didn't research it, I just did so after fixing it.

Thankfully, I didn't come up empty handed. I found Bug #90526: Routine fsck deactivates swap, changing UUID. Yep, that's it exactly officer. The clue this time was that I saw the fsck happen as my laptop booted, and realized that the last time seemed to be in close temporal proximity to a fsck as well. It's a confirmed bug, with no indication of a time frame for a fix. However, it's always nice to know that you aren't crazy, and that your issues have already been documented.

Hibernate once again!

So, the instructions I mentioned in my last post seem to have cured my swap & hibernation issued on my laptop for the time being.

The short version was:

1, determine your swap with 'fdisk -l'
2, do mkswap on your swap partition - RECORD THE UUID WHICH THIS COMMAND OUTPUTS
3, now use this UUID to put into fstab and resume files...RESUME=UUID=<the-swap-partition-uuid-from-vol_ID>
should go in /etc/initramfs-tools/conf.d/resume
4, update-initramfs -u
5, reboot normally after this finishes

What caused my problem in the first place is still very much a mystery though.

Reading through the threads, it appears that the general idea is that either the hibernate or the suspend failed for an unknown reason. This left the hibernation image stored in the swap space, which can apparently cause the swap space to be considered corrupted, and therefore not be mounted.
However, most of the comments indicate that in this scenario the UUID issues, which are what the above steps fix, only appear once the user has manually run mkswap, which changes the UUID of the swap partition. If, as Ubuntu defaults to doing, you are mounting partitions by UUID, and not just label, then once changed, mounting cannot succeed until the fstab is updated, manually.

However, in my case, I was already getting UUID errors when running swapon -va, which was why I began tracking down the problem in the first place. I certainly didn't run mkswap before the error appeared, so why did either a) the UUID change, or b) the symlink for the UUID disappear? That is half the mystery, and what caused the hibernate to begin failing is the other half.

However, for now it is functioning fine, so I probably won't be spending much time digging further into it, unless I have more problems with it in the future,

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 del.icio.us 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.

Mafiaa

Ok, so news like this makes me grin. While I understand that downloading copyrighted music is a civil offense, I really think suing your customers is a stupid business strategy. Although, I also think adding "Don't even think about pirating this you evil person you!" messages to CDs, and liner notes, and guilt trip clips before movies is just as insulting to the consumer, especially since you only see these after you've handed over your money, placing you firmly in the classification of paying customer.

However, even once we get over these issues, the way the RIAA primarily, and to a lesser extent the MPAA, are going about these lawsuits is ridiculous, and in many cases fraudulent. They threaten people with lawsuits to get upfront settlements, file anonymous lawsuits by the hundreds, and even tried to scold a college for not keeping IP address assignment logs because "Don't they know they are important?". Well, they may be important to the RIAA, but to the college they hold no special value, and consume valuable & expensive resources to keep around, so the logical choice is not to keep them unless they have a specific need for them.

I'm all in favor of people fighting back on these lawsuits, whenever they have the means to do so. Progress is finally being made too. With several cases having forced the RIAA to pay the defendant's legal fees, this may embolden lawyers to offer their services in exchange for any fees they can recover if they win, which would help more people get qualified representation. In another case, the defendant, who was ruled against on the main issue, has successfully gotten the court to question the ridiculous per song damage figures spouted by the RIAA.

Lastly, if you haven't already heard the joke, the Recording Industry Association of America (RIAA) and the Motion Picture Association of America (MPAA) should join together to form the Music and Film Industry Association of America (MAFIAA).