Recently in Xorg and all things X Category

Every Linux release, from Ubuntu Dapper and Debian Etch, all the way through the present day and my testing of the Ubuntu Lucid beta, I look to see if suspend/resume will ever work on my old laptops.

It's kind of like the Holy Grail ... of geeky Linux/Unix laptop users like myself.

It always seems like it's going to work but never does.

But things are looking up. Right now I can use the power/logout/other-stuff-like-that button in the upper right corner of the screen to select "Suspend," and the Toshiba Satellite 1100-S101 (Intel Celeron 1.2 GHz, Intel 830m chipset) will go into suspend. After that I can press the power button, and a few seconds later the machine will resume (meaning awake from suspend and actually work).

I don't know if this wizardry is due to the efforts of the kernel developers, Xorg developers, Debian developers or even Ubuntu developers, but if I can set GNOME to automatically suspend the laptop at a predetermined time after it has been idle and then come back the next day, hit the power button and have the thing actually turn on, I will hardly be able to believe it.

I thought Linux in general and Xorg in particular were throwing those of us with "older" Intel video chips under the virtual bus. I couldn't even get Ubuntu Lucid Lynx (10.04) Alpha 3 to boot on my Intel 830m (aka i830m and in my case Intel 82830 CGC)-equipped laptops, where my old standby of dropping i915.modeset=0 or nomodeset on the boot line would clear things up.

Today I decided to download and burn the daily build ISO of Lucid for March 15.

I booted it, hit Escape as soon as the first screen came up (that's a new one, having to do that), then hit F6 for Modes, arrowed down to nomodeset, hit Enter to select it, then Escape, then Enter again to boot ...

And a short time later I was in the less-brown-more-purple world of Ubuntu 10.04 LTS Lucid!

Never mind that it's ... purple.

It works! Video is perfect on my Toshiba Satellite 1100-S101 laptop with the Intel 830m chipset.

Whatever wasn't working for me in Alpha 3 has been fixed at the time of this daily build.

I'd like to thank any and all developers who were able to make this happen, and I'd also like to let the rest of the Intel 830m-using community know that the following WILL work if you turn off kernel mode setting with nomodeset in the boot line:

Ubuntu Lucid 10.04 (as of this 3/15/10 daily build)
Fedora 12
Sidux 2009-04

I have an alpha image of Fedora 13 but haven't yet burned it, and I have heard that Slackware 13 runs with no problem.

So the future for the older-Intel-video-using world is looking a whole lot brighter than it did a few short weeks again.

At this point I have no comment on purple or the window buttons moving from the right side of the window to the left. I have no comment because I DON'T CARE. I HAVE WORKING VIDEO AND THAT IS ALL THAT MATTERS AT PRESENT.

I'll address purple and window buttons at a later time. One thing I can say for sure is that this ain't the usual orange/brown.

Before I go, I've been testing Firefox 3.6 on the Mac OS X and Windows XP platforms, and this instance of Ubuntu Lucid is the first time I'm seeing FF 3.6 in Linux.

My first impressions are that not much is different in the PowerPC build for OS X, but I'm seeing huge improvements in the browsing experience in terms of speed in both Windows and Linux.

I can't say for sure, but I think it all boils down to a faster Javascript engine in 3.6 vs. 3.0 (and also 3.5 perhaps).

Getting back to Intel 830m for the moment, this means I'm upgrading my Debian Lenny laptop to Squeeze as soon as possible.

In addition to his first e-mail to me, David Gurvich adds more about his experiences with Intel i830m video in Linux and PC-BSD/FreeBSD:

I did think the problems with FreeBSD were due to using PC-BSD and installing a lightweight desktop on top. After testing with a bare install that turns out to not be the case and the issue is with FreeBSD and has nothing to do with the scripts that PC-BSD uses.

I have not tested OpenBSD but most of the wireless drivers on FreeBSD have been ported from there. I suspect there is a difference between the two that causes these drivers to crash the system on FreeBSD. The primary reason that I was interested in FreeBSD was ZFS support and wanted to setup a file server. The network issue stopped that in it's tracks.

There is a graphical network tool in the FreeBSD ports that seems to work ok but most of my settings were with wpa_supplicant and rc.conf. I believe that PC-BSD has it's own graphical network configuration tool but didn't use that.

Flash does have issues on FreeBSD and I don't recommend installing the linux compatibility to use flash. Instead, use wine with a windows browser. There is a memory leak in the linux flashplugin on FreeBSD that will eventually cause your system to freeze until you kill nspluginwrapper. The same technique may work on OpenBSD.

I have tried Fedora 12 on this laptop and that worked somewhat after tweaking a number of parameters. By somewhat I mean that I had random Xorg crashes and the tweaks simply mitigated the frequency. I gave F12 about 2 months but just could not take the crashes. Fedora 12 is working well on the other systems that I've installed it on but there was a problem with one that had ATI video which required building an xorg module from git.

I am currently using Arch linux on the X30 and, since configuring the boot parameters with 'nomodeset' and locking the xf86-video-intel driver to 2.9.1, have not had any issues with video. The main problem has been with the networking scripts and I am still not sure what the issue is there but installing wicd-1.7 seems to have worked around that. I am impressed with the speed vs Fedora 12. The reason I am impressed is that, prior to Arch, Fedora 12 had been among the fastest distributions on the X30 with a useable firefox in under 2 minutes. The X30 from startup to a working firefox connection takes 45 seconds in Arch.

The main issue I will have with Arch is likely the very reason Arch is so responsive. Rolling releases don't keep old packages around and new versions can cause random failures on working systems. That means that I will need to maintain a list of packages that should not be upraded and be careful on upgrades. Nothing new to anyone who has used Gentoo.

I've currently had Arch installed on the X30 for a month and have had no issues to deal with since the video and networking were fixed. The livecd boots to a text console and I recommend looking at the arch installation guide. Pretty much everything needs to be configured but the wiki makes that simple.

David Gurvich

David, you hit on a number of important points. I will definitely try Fedora 12 to see how it works with i830m, and I agree with you that Arch is an excellent choice. I've written many times about how the Arch community has been a great resource for me in solving my X issues with i830m all the way from Debian Lenny through now.

I neglected to mention ZFS in FreeBSD. That certainly is something to recommend in its favor. There's also a project bringing journaling to soft updates in FreeBSD's UFS filesystem that I heard about in this BSD Talk episode.

I'm not terribly happy about Flash being so problematic in FreeBSD. I forget all the trouble I had with the Opera browser in OpenBSD. That browser and its Flash plugin uses OpenBSD's Linux compatibility layer, and I was eventually able to stop most crashes by changing a parameter in Opera.

Here's what I'm hoping for:

• People smarter than me will figure this out and either make allowances in the kernel and xorg, or will create some other kind of mechanism that doesn't leave users of Intel 830m video chips out in the cold
• HTML 5 will sooner than later take hold with an open video codec and return Flash to what it's good at, which is little applications that I can safely ignore, and stop doing what it's bad at, which is delivering video that can better be handled by a plethora of other formats. The easiest way for this to happen would be for Google to open-source the on2 video codec it recently acquired. (Except that Google already converted the entire YouTube library to the loved-by-Apple patent-encumbered H.264.)

  I've run BSD before, and if Linux/Xorg throws Intel 830m under the bus, I'll be an enthusiastic user of any system that doesn't follow along.

Reader David Gurvich writes the following:

Hello,

I also have a system that uses the i830m chipset for graphics, the Thinkpad X30. All of the problems are related to kernel mode setting, particularly your current one. The new xorg video driver eliminates all user mode setting and is useless on systems that use i830. I've never gotten kernel mode setting to work with i830 systems and now that is the only option on new installs.

The only solution has been to install the 2.9.1 driver. That works for now but I am worried about future releases of Xorg that will not work with this driver. I suspect that I will need to maintain my own branch of Xorg. That will probably require a personal repository that includes older kernels, hal, and dbus along with any associated libraries.

My hope is that FreeBSD will have improved enough in user latency and other areas that I will be able to use that when the time comes. I have tried PC-BSD but the default install is too slow for daily use. I thought the problem might have been KDE4 but the issue persisted with a lightweight desktop environment. There are also some issues with hardware that don't exist on Linux. The one that springs to mind is my system locking up completely when the wireless card can't find a network on boot.

Thank you,

David Gurvich

Yeah, I'm not the only person hacked off about this. Here's what I wrote to David (knowing also that I'd run here as well):

Starting with Ubuntu Karmic and up through Lucid Alpha 2, and including Debian Sid (via Sidux 2009-04) at the end of 2009, I've been able to turn off kernel mode setting and get X to work.

So it was extremely disturbing to find that turning off kernel mode setting in Lucid Alpha 3 didn't work. Very disturbing.

I spent 6 months running OpenBSD 4.4 as my primary OS on this i830m laptop, and I didn't have any performance issues running both the stock Fvwm2 window manager as well as Xfce. The whole thing blew up when I upgraded to OpenBSD 4.5, and yes it was Xorg-related, but I've since tested OpenBSd 4.6 via the BSDanywhere and Jggimi live CDs, and Xorg is working again (can't remember if I needed an xorg.conf, but it must've either been easy to roll it together, or I'd have remembered.

The problems for me with OpenBSD are a) Flash 7 only (and only in Opera) b) too difficult to upgrade (which might be overcome if I can figure it out) c) hard to install Java (although I've done it and probably have the binary package I created in the process squirreled away on this hard drive) and d) no journaling filesystem, and on this creaky old hardware I lose power enough that all the fsck-ing I need to do in OpenBSD's FFS is relatively painful.

Not that I won't return to OpenBSD ...

FreeBSD is supposed to be much, much faster in every respect. There was a Phoronix test recently in which FreeBSD didn't blow Linux out of the proverbial water but did do OK. And it has at least Flash 9, precompiled Java packages, a much longer support cycle than OpenBSD, Ubuntu or Fedora.

If you tried PC-BSD but used, say, Fluxbox instead of KDE, I imagine the system would be much slower than if you installed vanilla FreeBSD and added the desktop environment and applications yourself. At least that's the theory anyway.

I don't know how FreeBSD uses memory, but I can tell you for sure that Linux and OpenBSD use it much differently. Linux seems to want to grab as much memory as possible and reserve it for whatever uses it thinks it's going to have. I don't know how this affects system performance - it could improve it, or it could hurt it. I'm really not sure.

But OpenBSD is very sparing on the memory it uses. I ran 768 MB for that six months in OpenBSD 4.4 and don't think I ever tapped the swap space even once. Now with 1 GB in both Ubuntu (Hardy, Karmic) and Debian (Lenny), the machine isn't relying heavily on swap but does use a little bit of it at least a little bit of the time. Again, I'm not sure which scenario is better for performance (or how FreeBSD factors into all of this), but it's at least a curiosity.

David, I don't know if you've tried Fedora 12 yet. I downloaded the image but haven't had a chance yet to burn it. Like you I'm looking for any bright spot in this whole mess. I don't know who to blame: the kernel team or Xorg (or the distros themselves). Intel i830m video can't be so obscure that nobody is suffering from this, and I can imagine hundreds or thousands of potential users being turned off when they can't get the live CD to boot to anything but a blank screen.

Before I forget to mention it, my experience with wireless on this platform with OpenBSD at least, is the opposite of what happened to you. Not only did wireless perform better with absolutely no crashes, I also was able to more easily configure my cheap NIC with a Ralink chipset in OpenBSD before I could get it working in Linux.

And crashes with wireless were precisely the reason I upgraded from Ubuntu Hardy to Karmic. I think a kernel update in Hardy eventually fixed the problem (I still have a Hardy i830m laptop running and can test this), and I wish I had stayed with it on the other i830m laptop. But networking in OpenBSD at least is a relative pleasure; networking and drivers are very important to the developers, so they get a lot of attention. However, you can't use the GUI tools like NetworkManager, I think, because of the vast differences in configuration between BSD and Linux (I could be wrong about this). Learning manual network configuration isn't the worst thing in the world.

After figuring out how to get the screen to work on my Toshiba Satellite 1100-S101 and Gateway Solo 1450 laptops — both with Intel 830m video chips (aka 82830 CGC, also called i830m by many) in Ubuntu Lucid Alpha 2, do you want to know how things "improved" in Alpha 3?

There's no improvement. Instead it's a massive fail.

Yep, another volley of "improvements" that undoubtedly helped someone had foisted on me the mother of all regressions.

The closest I was able to get was a working display with an invisible mouse pointer. Unfortunately I had forgotten which combination of parameters I typed into the boot line (a combination of turning off kernel mode settting one of two ways and setting a vga=xxx resolution), and after trying just about every VGA number I could find here, I've got nothing; no video at all on this Intel 830m system in Ubuntu Lucid Alpha 3.

In some way bowing to my issues — in my own mind at least — after booting the Ubuntu Lucid Alpha 3 live disc (CD or DVD), unlike the Alpha 2 you can now choose the nomodeset parameter from the F6 Other Options menu on the boot screen.

That's great, except that it no longer works for me.

How many potential new users of Linux have Intel video chips that are like mine? Do others besides the 830m have this problem?

All I know is booting a live CD and having absolutely no video is no way to get new users ...

In a related matter, I burned a DVD of PC-BSD 8. While the live environment is not exactly scintillating — it's KDE with barely any apps, it does boot into a graphical desktop that looks absolutely perfect with no intervention on my part. Yep, the FreeBSD and PC-BSD developers seem to understand that the video should just work, even for those of us unfortunate enough to be running 2002-era laptops with Intel video chips.

Should this not be the fault of Ubuntu but something that plagues all versions of Linux including Debian, at least I'll have PC-BSD 8.0 to turn to.

Or I could use the xorg.conf that makes Debian Lenny work for me and run Slackware 12 or 13.

As has been written in the comments recently, I should file a bug on this. If only I understood how to extract the seemingly dozens of log files needed to substantiate such a bug report (and to do so with a non-working screen), I'd probably go that route.

Regressions like this verge on the catastrophic. You can't just go cutting off entire swaths of hardware. I do seem like the only person complaining about this, so maybe there are fewer people using laptops with Intel 830m chipsets than you might think.

At this rate, my recent practice of burning these alpha discs is pretty much over. The Ubuntu Lucid release day is less than two months away, and I'm going to wait until that time to try this LTS (long-term-support) release again.

That also means I'll be sticking with Debian Lenny until there's some kind of live environment that I can test before any upgrade to Squeeze.

Before I wrap this up, yes I realize that this isn't even beta software but alpha, and there's a good chance my video issue will be resolved, but seeing things go from "pretty good" to "no can do" instead of the other way around is more than a little disconcerting.

My laptops using Intel 830m (aka i830m ... aka 82830 CGC) video don't like kernel mode setting. They don't work with it.

But turning it off, they work wonderfully with no xorg.conf in anything with a 2.6.32 Linux kernel — and that means Ubuntu Lucid (currently in Alpha 3 stage, though I'm using the Alpha 2 image at the moment) and Sidux 2009-04 (and presumably Debian Squeeze, the current Testing release for the distribution).

Until now I've been turning off kernel mode setting in the boot line with:

i915.modeset=0

I just discovered, tested and confirmed that this boot parameter does the job just as well:

nomodeset

The latter's a bit "cleaner," don't you think. I promised in a comment that I would look into bugs related to this problem, but things look in a whole lot of disarray. Some people submit so many log files, outputs and other things that I wouldn't have the expertise to assemble in a dozen years. Others haven't yet landed on the solution I've written about in a couple dozen of these entries.

So unless someone out there can direct me to the "best" bug in either Debian, Ubuntu, Xorg or the Linux kernel itself, I'm gonna stay out of it and just continue writing about it here.

Am I the only person out there with not just one but THREE laptops using the Intel 830m chipset?

If not, either of the two boot parameters mentioned above make the X problem go away. I'm sure kernel mode setting is a wonderful thing, just not for this particular graphics chipset.

Before I get into this entry, after I wrote it I saw the following in the Sidux release notes:

Kernel 2.6.32 doesn't only improve and stabilise hardware support for newer devices, it also allows enabling KMS (kernel based modesetting) for Intel graphic chipset ...

Note to Linux kernel developers: This doesn't work with the Intel 830m. DOESN'T WORK.

And now back to our regularly scheduled post on how turning off kernel mode setting is the best way to get "today's" Linux distributions to boot into graphical desktops on computers with the Intel 830m graphics chipset:

Remember the last time I figured out how to run both Ubuntu Lucid (via the Alpha 2 image) and Sidux 2009-04 on my Toshiba Satellite 1100-S101 and its Intel 830m video chip (aka Intel 82830 CGC)?

I used two methods: using the VESA driver and turning off kernel mode setting.

Both methods worked in Ubuntu Lucid — the project's upcoming 10.04 LTS (long-term support) release.

I tested the live KDE DVD image of Sidux 2009-04 for a number of reasons, one being that I think Sidux is a great project that allows users to run the "unstable" Debian Sid with a minimum of pain, all the while providing a very usable desktop. The other reason is that I know of no other live image (especially a live DVD+R, which my quirky Toshiba likes much better than a CD-R) with which to test the upcoming Debian Squeeze release, now in Testing but eventually slated for Stable designation.

The equally useful Debian Live project allows prospective Debian users to try out Debian on their hardware before committing to a full installation — just like Ubuntu and many other popular distros. As far as I know, you can't install the distro from the Debian Live image, but it is invaluable in terms of seeing how a given computer will respond to Debian.

But Debian Live doesn't appear to have any DVD images (I'm not sure whether or not a CD image can be burned to a DVD+R disc; if anybody out there knows anything, please let me in on it). And I don't see any Squeeze images. They appear to be in Lenny-only mode.

So I turn to Sidux. Despite the "2009-04" tag line, it was released in December 2009. I'm sure Debian Squeeze will move further along by the time it is released as Debian's stable distribution, but it does allow users to try something farther from Lenny and closer to Squeeze without committing to a full installation.

So today I decided to try to boot Sidux not with the VESA driver but by turning off kernel mode setting.

As with Ubuntu Lucid, I started to boot the Sidux 2009-04 DVD, and at the boot screen I added the following to the boot parameters:

I was soon in the surprisingly snappy KDE 4.3.4 environment.

This leads me to believe that turning off kernel mode setting will allow users of Intel 830m video (and most likely other Intel video of similar vintage) to not only run Ubuntu Lucid but very like Debian Squeeze as well. In case it's not implied, for me this is huge. It means I'll have choices as to where to go after Debian Lenny.

While in the Sidux live environment, which I'm enjoying very much by the way, I worked a bit in both the Kwrite and Kate text editors, both of which run great on this machine (1.3. GHz Celeron, 1 GB RAM) — much better than the last time I moaned and complained about KDE.

Sidux with KDE on this live DVD — and on this not-so-new hardware — seems no less responsive than Debian Lenny with GNOME. I guess that means I'd be more inclined to use KDE in the future, but I imagine I'll be sticking with GNOME at present (if only because it's working well for me).

In case the message got lost in all of this, the main thing I'm trying to say here is that kernel mode setting is becoming an increasingly big deal in Linux, and for users of Intel video, it not only doesn't help but pretty much renders the given distro unusable.

Turning off kernel mode setting is the key to actually having a working computer and if you can't boot either the live disc or resulting installation and get a working desktop, this is a tweak you should try before messing with xorg.conf or pulling what's left of your hair out.

Attention developers: This "improvement" you call kernel mode setting is pretty much a regression for users of my particular video chip, the Intel 830m, and could be equally useless for other Intel video hardware. Maybe figuring out why kernel mode setting doesn't work in these cases is the thing to do? And how about dropping in some code that automatically turns off kernel mode setting on hardware that doesn't like it until this show-&*^-stopping bug is dealt with?

I don't know who to blame here. I'm no expert, but my gut reaction is that this is a kernel-development problem. My question to you users and developers out there is this: Is kernel mode setting working for you and your Intel video hardware?

Before I end this entry, did I mention how much I like Sidux? I could get used to a distro this good. I'm not the kind of person who needs or wants the latest in everything. To me stability and lack of breakage is key. But just like the first time I tried Sidux (with Xfce), I'm extremely impressed by what its developers have done — and by how quick and usable Debian — be it Sid, Squeeze or Lenny — continues to be.

Me and Xorg. It's a long, dramatic tale.

OK, it's not so much me and Xorg as it is my Intel 830m graphics chip and Xorg, or more specifically my Intel 82830 CGC and Xorg.

Whatever you title this epic — and make no mistake, this is epic, let me preface this by saying the c%$ I've been through since the days Debian Lenny was in Testing is something I wouldn't wish on any other user.

If you want to read every sordid detail, start with my three-part series, or just read my fix for Ubuntu 9.10 (Karmic Koala).

Long story short, I've managed to get my Intel 830m laptops (yes, I do have more than one) to run in Debian Lenny and all the Ubuntus from 8.04 through 9.10 with the various methods detailed in the posts above.

There are two ways to go about this. One involves hacking into xorg.conf to make the display work. The other involves disabling kernel mode setting.

In Ubuntu 10.04 (Lucid Lynx) Alpha 2, which I've been testing with a live DVD, there are two ways to boot the disc and get actual video.

The first is booting in "Safe Graphics Mode," which invokes the VESA driver.

The second is something that worked for me in at the beginning of the 9.10 era, which I didn't need later but now seem to need again in 10.04. And that is disabling kernel mode setting.

Both of these methods work, but I prefer the second, disabling kernel mode setting, because a) you're not using the VESA driver and b) you are running X without an xorg.conf file, which is something I quite like to do (and have done in OpenBSD and a few Ubuntu releases).

To run in Safe Graphics Mode, once you boot the Ubuntu Lucid DVD, click F4 for the various "modes," and select "safe graphics mode." Then click Enter to either "Try Ubuntu Without Installing."

You will boot into Ubuntu Lucid, and the system will create an xorg.conf file that calls the VESA driver.

It looks good. It is good. I don't think you'll be able to get Compiz, but I couldn't get it with my other method either. I've been able to use Compiz before on this hardware, but I always disable it anyway because all that wobbling and sliding makes me nauseous (literally).

I prefer the second method, disabling kernel mode setting. I wrote up this hack for Ubuntu 9.10 Karmic, and it works here just as well.

Here's what you do:

You need to get to the Boot Options line. Do that by hitting F6 (Other Options). Don't actually choose one of the options presented. Instead, click your Esc key. The Boot Options line should appear just above the F1 through F6 line at the bottom of the screen.

To access that Boot Options line, just hit one of your arrow keys, and your cursor should appear. At the end of the Boot Options line — after quiet splash — enter the following:

i915.modeset=0

Then click the Enter key to boot into the Ubuntu 10.04 live environment.

If this works for you the way it works for me, you'll soon be in the Ubuntu desktop, and if you open a terminal and run:

$ cat /etc/X11/xorg.conf

You'll see that you don't have an xorg.conf, but you're in X. And it works. I like that.

I tried to turn on Compiz just to see if I could, but it didn't work.

If turning off kernel mode setting works for you in the live Ubuntu 10.04 environment, what do you do if you want to actually install Ubuntu? How do you turn off kernel mode setting permanently?

(Remember that while I initially needed to turn off kernel mode setting in Ubuntu 9.10, at some point in the update cycle I was able to turn it back on ... before I started having more trouble with X, prompting me to retreat to Debian Lenny, which I'm running on my main laptop right now.

Ubuntu 10.04 is only in the alpha stage now. This issue might be "fixed" by release time in April of this year. Or not. But you can always try this hack if you have trouble.

I'd love to tell you how to make this kernel mode setting fix so the GRUB bootloader will turn it off every time you boot into Ubuntu, but I can't. GRUB has "moved on" to GRUB 2, and it no longer works the same way as the GRUB I've been hacking into for three years now.

And now I'm hearing that GRUB 2 isn't quite ready for production from a security standpoint.

Update: Here's a pretty good tutorial on working with GRUB 2.

I did a little checking around — and I encourage any of you to do the same, since I'm not running GRUB 2 on an actual install — and it looks like you can add boot parameters in /etc/default/grub, then run update-grub to update /boot/grub/grub.cfg.

It looks like the line in /etc/default/grub with "quiet splash" in it could be appended with i915.modeset=0, and after saving it, you run update-grub, and then you should be good to reboot.

Again, I don't have Ubuntu 10.04 installed on any boxes, so I'm speculating here.

If I'm correct (and I'd love confirmation):

You open a terminal and use sudo to accomplish this (with your favorite text editor; I'd use vi or nano, but I'll use Gedit here because I imagine the average Ubuntu user is plenty comfortable with it):

$ sudo gedit /etc/default/grub &

Then when you're in the file, change this line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to look like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=0"

Save the file in Gedit and close the window.

Then run this command:

$ sudo update-grub

You should now be able to reboot the machine and have GRUB turn off kernel mode setting automatically. If not, I imagine there's a way to edit your boot line "on the fly" like there is now with the "old" GRUB. (Again, if anybody has installed Ubuntu 10.04 and can confirm this, I'd really appreciate it).

My initial impression of GRUB 2: I like the idea of GRUB 2's configuration files being in /etc instead of in /boot/grub. It makes it easier to keep backups, and if you kill the bootloader (as I have on many an occasion) with a dual-boot install, you'll still have your configuration, or so I think.

Hello LTS: Disabling kernel mode setting worked for me in the early 9.10 era, and at some point either a kernel or Xorg update made it so I no longer needed it. Now it seems that I need it again to make Intel 830m (82830 CGC) video work. Whatever. If disabling kernel mode setting makes Ubuntu 10.04 work, I've just bought three more years (Lucid is a long-term-support release) of security updates in an OS that I like a whole lot.

What about Squeeze? Does Debian Squeeze use kernel mode setting? I ask because I had the same problem in Sidux 2009-04 (which I used to peek in a live-disc kind of way into what Squeeze might be like), and the Vesa driver came through for me there. At some point I'll try turning off kernel mode setting in Sidux and see what happens.

This kind of BS amounts to one thing and one thing only: New user repellent. If you haven't been hacking around with Xorg for years, and you're just thinking of trying Ubuntu and happen to have a laptop like mine — of which there are MILLIONS out there, Intel video being pretty darn ubiquitous — you're going to get a Ubuntu disc, try to boot it, get no video and wonder what all the fuss is about Linux since you can't even get to the desktop. It's a huge fail.

How could Ubuntu (or Debian, Slackware, Arch ...) solve this issue? During hardware detection, if the Intel 830m graphics chip comes up, use a script to turn off kernel mode setting (and if this hack works for any other graphics chips having this same trouble, include them in this "configuration" script). There's no reason why a very common graphics chip shouldn't work without resorting to the kind of hackery that's way, way above the pay grade of almost every new Ubuntu user.

I'm reading one of my very favorite FOSS writers, Ryan Paul, on the changes afoot for Ubuntu 10.04 LTS (codename Lucid ... and I hope so), and before I continue, I heartily recommend reading everything Ryan writes in Ars Technica's Open-Ended blog, but this comment (among the many) leapt right out at me:

"I'm looking forward to this release. 9.10 is mostly stable, I could use a good update that breaks my intel video and wireless chips even though they were fine, plus overhauls the USB method so not much works anymore."

That's exactly where I'm at. I had a pretty good thing going in Ubuntu 8.04 LTS. Everything that was ever going to work pretty much did. Yeah I had a bit of instability with one of my wireless adapters, fixed in 8.10/9.04, and I fairly quickly figured out how to tame the new NetworkManager (upgrading with wireless from 8.04 is NOT recommended, by me anyway, if you plan to use a wired interface after the fact).

And I did the upgrade from 8.04 through 8.10 to 9.04 in a single weekend solely to be ready for 9.10. As I've said more than once, I wanted newer apps, and I had no idea so many things would break.

But break they did.

If I hadn't suffered through similar problems — all since solved — in the transition from Debian Etch to Lenny on my Intel video hardware, I'd be more critical of Ubuntu than I already am. (Hard to believe, you say? I agree.)

I realize this is one of the problems inherent not in software distributed under free, open-source licenses and developed by the community.

No, it's due to one thing and one thing only: Hardware manufacturers.

These hardware manufactures have spent untold hours making sure their equipment has the proper drivers to function under an increasing number of Windows operating systems. I've seen drivers offered for everything from Windows 95 through 98, 2000, XP and now Vista and 7.

If these hardware companies paid the same kind of attention to Linux, and in addition didn't just push binary blobs out the tube but offered open-source code that could be used in any number of operating systems, from those based on Linux to BSD and beyond, then we'd be getting somewhere,

I spend a lot of time bitching, moaning, complaining and rending garments over the problems I have when Ubuntu or OpenBSD does a six-month update that takes my X video compatibility and rips it apart. And while I think the lion's share of responsibility for the huge regressions in Intel video compatibility belongs to the Xorg developers, I really don't know how and why Intel either aided or allowed this to happen, as well as why so many operating-system projects just took this code, rolled it into their OSes and made me and so many others suffer so much (and again ... this has been going on for me at least since Debian Lenny was in Testing).

I've had a few comments that my now-8-year-old, most-likely-crappy-from-inception Intel hardware is being cast adrift to make things "better" for the newer video hardware out there. To that I say, bullshit.

My 2001 laptop with 1 GB RAM and a 1.3 GHz Celeron is perfectly capable of running "today's" Linux and BSD operating systems, as well as Windows XP (which I wiped from this PCs hard drive many months ago).

As I've said before, I don't know if there's any way of telling just what the mix of machines running Linux and BSD is out there, but I have a very good feeling that there are a whole lot more "older" machines than "newer" ones running FOSS operating systems.

If I knew more about Xorg, Intel video chips of a certain age, kernels and drivers, I would no doubt be better equipped to place blame for what I and many thousands of others have gone through over the past 2+ years.

I'll leave Ubuntu's seemingly silent decision to change the way it deals with USB drives (as the commenter mentions, as have I) since that's yet another issue I've dealt with (I had to modify all of my rsync shell scripts).

Would I do better with a Thinkpad? More developers use those than Toshibas like mine, so that would be a good choice.

But for what I pay for hardware (and that's as close to nothing as I can), I pretty much run the machines that find their way to my doorstep.

All I want are upgrades that don't completely break the OS. That's it. I like new apps, but what happened to this Toshiba Satellite 1100-S101 with Ubuntu 9.10 is not OK.

Like I said in a recent entry, there's a lot about Ubuntu to like, and many things about the operating system itself and the project philosophy have kept me using it in one form or another since 6.06 LTS. (And if OpenBSD hadn't blown up on me between 4.4 and 4.5, I probably would've stuck with that even longer than the six months I did; different story, different circumstances.)

I realize this is free software, but I don't think most developers and users think we're in this for anything but victory over the ways and means of proprietary software and the conglomerates behind it.

And I also realize I'm not a developer, just a user with logorrhea.

But come Lucid time in April of next year, the way I feel now I'm not going there in any kind of rush. Maybe three months, maybe more ... maybe not.

Note: Turns out my screensaver "fix" described below didn't work.

Click back a few entries and you'll know about my recent GNOME Screensaver issue in Ubuntu 9.10 (Karmic).

First thing: I did a screensaver test over the past two days (it went a day longer due to my daughter being sick and home from school and the Toshiba Satellite 1100-S101 laptop being at the office, plugged into an external monitor due to the screen physically dying a slow, unrelated death).

The result of that test is that I seemingly CAN get a form of "screensaving" to work without totally losing both the keyboard and mouse after a period of time, requiring a hard reset to bring the laptop back to life.

Second thing: When I came back to the machine this morning, the new Ubuntu way of notifying users of a software update had plopped an Update Manager window on my desktop, a screen shot of which I present above.

This GNOME Screensaver bug-fix seems to have nothing to do with my problem, that being the screensaver killing both keyboard and mouse after a time on my Intel-video-running machine.

But maybe, just maybe it'll make things better. Could make them worse. I haven't quit out of X or rebooted (or even installed the update yet).

Meanwhile, how did I get the screensaver to work yet NOT kill the whole machine?

First, under System - Preferences - Screensaver, I unchecked the box next to "Activate Screensaver When Computer Is Idle":

I've never understood why GNOME sets screensaver preferences in the System - Preferences - Screensaver dialog but then has further screensaver settings in the System - Preferences - Power Management dialog (which is also accessible from the Power Management button on the Screensaver dialog box).

I always wondered if these two screensaver setting somehow conflicted. I still don't know. But I set the screensaver preference in the Power Management dialog box:

Thus far that seems to work. Like I say above, the bug report that prompted this update of the GNOME Screensaver doesn't appear to have anything to do with my issue. This bug is about the screensaver not activating when it's supposed to, and my issue is about the screensaver eventually shutting down the keyboard and mouse.

But I've learned that when packages are updated to fix one thing, there are often regressions in other areas.

Right now I'm going to do the update, reboot and then see how the screensaver runs.

I did say recently that I needed a break from Ubuntu, but getting this installation back to where it was before the most recent Xorg update.