Wandering Thoughts archives

More Fedora Core 4 problems with X

Important update: the buggy RPMs have been superseded. See the end.

You may remember back to FC4FirstIrritations, where I talked about several X problems. Well, Red Hat managed to outdo itself recently, as we discovered the hard way: their latest update to the xorg-x11 packages, 6.8.2-37.FC4.48.1 (released September 16th or so) now causes almost all of our workstations to explode.

Not literally exploded, but X won't start and more or less crashes the machine (one bug report compared it to what a crashed C-64 looks like, and I have to agree). It turns out that this update appears to be totally broken on many if not all Intel graphics hardware, such as the 865G chipset that our HP Deskpro D530s.

The Red Hat Bugzilla bugs filed so far are #168919, #168937 (i945 graphics), and #168940 (i865G graphics). They've apparently all been filed very recently, which at least makes me feel somewhat less annoyed.

Unfortunately, we mirror the entire Red Hat updates repository and use yum, which requires carefully built repository metadata. This means that clearing this update out of our system is not as simple as removing the RPMs; we have to fix our mirror scripts, move to manually building the repository metadata, and then test the result.

Since a reinstall test takes half an hour or more, there went a lot of my day. Fedora Core 4 has really turned into the update that I wish we'd skipped.

Clearly, we need to adopt new rules for Fedora Core 4 updates:

1. never apply updates within a week of their release (unless they are urgent security fixes).
2. always check Bugzilla for new bugs caused by the updates.

It's a rather sad day when we have to adopt these rules, but that is apparently life with Fedora Core 4.

(You may gather that I am not happy with this state of affairs.)

Update, September 23rd: The good news is that this issue has now been fixed; today Red Hat released a new xorg-x11 update, version 6.8.2-37.FC4.49.2, that doesn't have the problem. The master Bugzilla bug for this issue turns out to be Bugzilla #168752, which has various bits of information.

I am still somewhat unhappy about this state of affairs, but less unhappy than I was when I first wrote this entry. Part of it is that the problem is gone; part of it is that Red Hat dealt with the issue pretty rapidly, without dragging their heels (as I feel they have with some Fedora Core 4 bugs). I do think that Red Hat needs a procedure for pulling seriously problematic updates from their updates area (and the mirrors, which makes it more challenging), and that they should have used it in this situation.

What vendor updates are pending on your Linux system?

One of those routine system management tasks these days is checking to make sure that I'm up to date on vendor security releases and other updates. And when I'm not up to date, I generally want to know what's out of date; being out of date on diff is one thing, being out of date on a kernel or glibc is quite another. (For a start, I probably want to test the kernel a bit more before pushing it into our local update queue.)

Since I have a lot of systems, I like a concise report; say, one line with all the pending packages for systems that need updates, and total silence from systems that are current (in other words, I'm a Unix geek and I like Unix-style output).

Unfortunately, most package management systems are not quite as eager to accommodate my minimalism as I would like, so it takes some scripting work.

For anything with yum (Fedora Core, current Red Hat Enterprise, and probably others):

yum -d 1 check-update |
  awk '{print $1}'

In at least Fedora Core 4, this doesn't give you the literal package names; you get a bonus architecture glued on the back that you'll have to slice off if you really care. You also get a bonus blank line at the start (this may be a yum bug).

Debian makes it a little bit more annoying. I get to do:

apt-get -qq update
apt-get -qq -s -u upgrade |
  awk '$1 == "Inst" {print $2}'

(Assuming that Debian does not change apt-get's output someday. They might, and this is one reason apt is not my favorite program.)

In theory 'apt-get -qq update' could be dangerous, but I think the odds are pretty low.

Converting these to produce single-line output is left as an exercise to the reader.