My Webpage Addiction

So, yesterday, I had a recurring issue happen to me, which causes me much frustration. I lost about 100 webpages in Firefox. Yes that's right, I lost webpages. Ok, let me explain what I mean.

First, I have a problem. I collect webpages. I think that's about the only way to describe it. I will find a new webpage through any of a variety of means. I might open 15 pages from search results when I'm trying to troubleshoot a problem, or I might follow some links from various webcomics, or be sent something by a friend. Then, for whatever reason, I don't just read the page and move on. Instead, I save it. Either because I don't have the time to read it entirely right now, or I want to try it out later, or I think it's great reference material to keep around, or I want to send it to someone else. So for whatever reason, I want to keep it around.

Because of this, I've got hundreds of untamed bookmarks, synced between browsers, in theory, whenever Google Browser Sync works properly. (It synced at the beginning, but I'm not sure about lately.) I've also got a del.icio.us list that is 234 pages long at 10 items per page. And lately, I've become known (read as:ridiculed) for having as many as 150 tabs open in several windows in Firefox at any given time. Yes, starting Firefox is a 15 minute ordeal.

The strategy of just leaving the tabs open, works best for things I just haven't had time to read, or want to try in the next day or two. In theory. So, pre-Firefox 2.0, I use an extension to save my tabs, and restore them in case Firefox crashed on me. It also had the nice extra of saving the last 2 sessions, so if for some reason it didn't load my tabs properly, I could go back to the previous saved version. (Just don't close Firefox after not having your tabs load, or you will lose the good saved session information.) Firefox 2.0 came along, and with it, integrated session saving. This has been nice, and is more robust that the extension I relied on before (which is no longer compatible with current versions). However, it does not have the ability to re-load the session, or to load an older session.

Why does this matter? Well, I usually have the most tabs open on my laptop. And, for whatever reason I haven't tracked down yet, this is also my least stable installation of Firefox. I deal with a few crashes each day, on average. My laptop also has a quirk dealing with its Wifi, often requiring me to powercycle the radio before it will connect. Thankfully, it's just a key press on my laptop. However, if I fail to realize I'm not connected before I launch Firefox, or if (as happened this last time) Firefox gets auto launched because it was open when my previous X11 session ended, then all my tabs come up unable to connect. Once this happens, I have to go connect to the net, then reload each tab by hand. If I don't, then they will be saved as blank tabs, and Firefox will forget what site was previously loaded in them. Once this happens, they are usually gone, because I obviously do not remember what I had loaded in 150 different tabs. In addition, many of the tabs have been open for weeks, or longer, so they will no longer be listed in my browser history.

So, today, when my laptop decided it wasn't going to resume from suspend anymore, but would instead hang on booting, I managed, through a serious of events, to have this happen. This is probably the tenth time or so I have lost my tabs. It really, really ticks me off. So I decided to see what I could do about it. Unfortunately, the answer is, if I had known what to do, and had been quick enough, I might have been able to save them. Maybe. Depends on how far gone they were once I got the rest of the system functioning again. (How does Gnome just forget you had a notification area on your taskbar?)

There is an API available, with something vaguely like what I would want, mentioned as a potential use case. However, my coding skills are infantile, and creating a program to utilize this would be way beyond me. I did, however, come up with a stop gap measure. I added an entry t o have logrotate copy the session saving information for me (which is updated routinely as Firefox runs). This means, in theory, that I will have snapshots from several days available, and hopefully anything added after the snapshot was taken will be recent enough to still be found in my history.

Yes, I do realize that the real solution is to change my habits, and stop leaving so many tabs open. However, this is my stopgap solution. Time will tell if it works or not. May I never need to use it.

My configuration entry for logrotate:

/home/madasi/.mozilla/firefox/8ryaickb.default/sessionstore.bak
/home/madasi/.mozilla/firefox/8ryaickb.default/sessionstore.js {
        rotate 7
        daily
        copy
        dateext
        compress
        missingok        

}

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).

OTM Extensions

There will of course be lesser used variations of the OTM interval.

The MTO interval is for when a device is un-impressive at first, but you later discover something about it that really changes your opinion of it. This will be a very subjective measurement, and therefore be much more difficult to quantify and measure.

There will also be a MTOTM interval, measuring the time from getting an un-impressive device, discovering something cool about it, and then deciding that the device is still pretty lame afterall.

This Post has an OTM rating of 2 days.

So, in conversation today, we created the OTM rating scale for new technology. This is how long from the time of purchase it takes for your opinion of the item to go from Ooh! to Meh! This should be a required statistic listed for all new devices. This was discovered while playing with a POS at work. (That's Point-of-Sale, keep it clean!) I discovered an unlocking lever on the monitor, and said Ooh! I then played with it, and discovered that it was already at the best position, the others were horrible, prompting a Meh!. We then observed that it took about two seconds to go from Ooh to Meh, and the OTM rating was born!