Ubuntu fixes Karmic kernel-mode-setting graphics bug for Intel chips (and renders me a happy Karmic user)

Somewhere between the debut of Ubuntu 9.10 (Karmic Koala for those into animal names) and today, the developers/maintainers/overlords of what many consider the leading Linux distribution have fixed the dreaded "kernel mode setting bug" that rendered the X Window system on many computers using Intel video hardware unusable until kernel mode setting was turned off.

I found a fix for this fairly quickly, as I have for the other Ubuntu-related problems befalling one of the two Toshiba Satellite 1100-S101, 2002-era laptops I rescued from the to-be-recycled heap when the Daily News moved offices what now seemed like a millennium ago.

Back to the kernel-mode-setting issue. I barely understand the reason for kernel mode setting, although my faint grasp of the details involves something about the kernel configuring the X server (or perhaps I should just say "the video") and not the Xorg program itself. Seeing a blank screen after booting my first time into Ubuntu 9.10 was not a welcome sight.

As I said, I quickly found the way to turn kernel mode setting off for Intel video, but I thought this potentially show-stopping bug was a bit of a turnoff, shall we say, for potential, new and/or less-experienced users of Linux.

Well, somewhere along the way, this bug was fixed.

How do I know?

Due to another seemingly ill-advised change in the way Ubuntu does its thing — namely lamely notifying users about software updates at intervals that even an ancient astrologer couldn't ascertain and in a most obtrusive way, botching a process that used to be quick and clear — I've been doing my updates in the terminal using Aptitude (which I find usually does a more complete job than apt alone when installing, removing and updating software in apt-based system such as Debian and Ubuntu).

Today I opened a terminal and did the usual:

$ sudo aptitude update

followed by

$ sudo aptitude upgrade

Some 50+ packages, including the kernel, were in need of an upgrade. (After completing this process, which installed kernel 2.6.31-15 to replace 2.6.31-14, I checked the "older" kernel, and it does X just fine with kernel mode setting, so the fix must either be in the older kernel or another package in the system.)

I don't know if the usual Update Manager or apt would have done this in the exact same way, but as part of the aptitude upgrade process, a message in the terminal asked me how Aptitude should handle my /boot/grub/menu.lst file, since it was "locally modified" (can't remember the exact wording, but that's the gist) and needed to be changed to accommodate the kernel update.

And if you've followed this tale of woe, you already know I had modified menu.lst, the configuration file that controls how the GRUB bootloader works, to turn off kernel mode setting for the i915 driver and get the display working once again in the GUI right after my upgrade from 9.04 to 9.10

I knew how to replicate the fix (stopping the boot process while GRUB was running, turning off kernel mode setting by editing that line in menu.lst for that boot and then going into menu.lst to add the fix permanently), so I let the system replace my /boot/grub/menu.lst with the one "provided by the maintainers." (Again, I'm paraphrasing; guess I should have done a screen shot. And while we're at it, who exactly are The Maintainers? Wasn't that an '80s band? ... I digress.)

I let the system rewrite GRUB without turning off kernel mode setting. Aptitude finished upgrading the system, and the system prompted me to reboot.

I did. I expected X to be inoperable after the system booted up, but much to my very pleasant surprise, everything works perfectly, X included. And still no xorg.conf is needed.

So for my system anyway, which uses the Intel Corporation 82830 CGC [Chipset Graphics Controller]. as lspci tells me in a terminal, X is seemingly as good as if not better than it's ever been.

And that means Linux in general, Xorg and Ubuntu in particular, appear to be cleaning up what has been a long graphics nightmare for Intel-powered video (and that's a whole lot more people than should've been put through what we've had to endure over the last very long while).

Like I said, Aptitude hasn't asked me until today to modify /boot/grub/menu.lst. I had been meaning to do a test of kernel mode setting to see if anything had changed, but right now I know it has.

I always say you should wait at least a month if not two before installing a new release of just about anything, especially Ubuntu. And if I had waited a month, I'd be upgrading to Karmic right about now, presumably with all the bugs fixed that have troubled me since my initial upgrade (chronicled painfully in a three-part series that somehow, some way, sprouted a fourth part with a flurry of follow-ups).

My review of Ubuntu 9.10 during the first week I used it was much more critical.

But now, at Ubuntu Karmic +1 month, I'm happy to the point of mild delirium (in a good way).

And my Ubuntu motto is now: Good (and patched) things come to those who wait.

What about the other Toshiba?: The other Toshiba, unlike the Ubuntu-running model, has a working CMOS battery, and also unlike the Ubuntu Toshiba, has a dead sound chip and a spotty display that, due to a bad inverter or something like that, needs the lid-operated screen-blanking switch to be pressed by hand every once in a while to bring the display back to life.

That "other" Toshiba formerly ran OpenBSD 4.4 until the whole thing blew up in my botched 4.5 in-place upgrade. It now runs Debian Lenny (and very well, too) with fully encrypted LVM. I'd have only encrypted /home and /swap, and perhaps also /tmp, but between you and me, that kind of thing is just too hard.

Hell, encrypting /home in OpenBSD is too hard. You'd think that in an operating system famed for its security and paranoia, creating an encrypted /home would be easy as peasy (and by that I mean a choice offered during the installation). But no. OpenBSD does encrypt /swap by default, I believe, and I wish it would at least give the installing user the option of encrypting other partitions without more extensive geekery than is already needed to get an OpenBSD system up and running.

I know. I! KNOW! that Ubuntu now offers users the ability to encrypt /home during the install (and there are forcefully geeky ways of turning an unencrypted /home into an encrypted one), but since all of my current Ubuntu installations began their lives with the live CD installer for 8.04 LTS, I haven't had the opportunity to choose an easily created encrypted anything.

And since the Debian text-based installer (as well as the nearly identical Ubuntu "alternative" installer) has offered fully encrypted LVM at least since Etch, I chose that for this experimental/backup Debian Lenny installation. I still think that carrying around a laptop with unencrypted personal data is a very bad idea, and I really shouldn't be doing it. But I'm too damn lazy to reinstall Ubuntu from scratch on my main Toshiba (or go through the aforementioned geekery to do it after the fact).

Now my plan is to wait — WAIT! I SAY! — for the next Ubuntu release, 10.04 LTS, to age a few months (like a homemade wine, which I also hope to craft in my garden shed, backwoods/prison/old-country-style) before doing a complete reinstall on whatever my main machine is at that time, during which I will encrypt /home, /swap and probably /tmp as well, keeping an unencrypted backup on a physically secured (i.e. off-site) USB-connected drive.