First irritations with Fedora Core 6

October 30, 2006

In the tradition of previous entries, some first irritations with Fedora Core 6. All of this is on an x86_64 upgrade from Fedora Core 5 on a machine with a stock configuration and stock GUI, and is mostly about the upgrade process.

  • I had to manually specify noapic on my hardware. This is not too surprising, since the regular FC5 kernels now need it, but the FC5 install kernel was fine without it.
  • at least if you have a non-RAID root device but software RAID on other devices, the upgrade process will bomb out, unable to mount them. Fortunately I did not have anything important on these partitions, so I was able to just comment them out of /etc/fstab. (On closer inspection, this is probably #188314; while my software RAID has two mirrors, I accidentally created it so that it thinks it should have three by fumble-fingering how I wanted to handle spare devices. The good news is that this won't affect my primary machine.)
  • the dependency checking phase seems really slow. There is some indication (eg #211896) that this is fixable with 'rpm --rebuilddb' beforehand, but RPM database rebuilds usually make me nervous.
  • upgrading is surprisingly slow, possibly as a side effect of the previous issue. Although I didn't time it, Anaconda claimed over 60 minutes and I can believe it.
  • the update process spends too much time looking like it has hung, with the progress bar static and the mouse cursor a plain cursor instead of the spinning 'things in progress' one. Under the circumstances, this is a bit unnerving.

The heart-stopper is what happened when I commented my LVM filesystems back into /etc/fstab and rebooted: the system screeched to a dead halt with an inability to find any LVM volumes (and complaints about /dev/hdb, the DVD drive I'd installed from, not being there). After a great deal of hammering on things, I wound up deleting /etc/lvm/.cache to fix the situation. LVM appears to use this file to cache what devices to scan, and it got reasonably mangled at some point during the upgrade, probably when Anaconda was scanning things after it failed to bring up my RAID devices.

Overall I think I like the new DejaVu fonts (and I might not have really noticed the change if not for Pete Zaitcev's potential misgivings from some time ago). The new monospaced font is makes the difference between O and 0 much clearer, although I am not sure about 1 and l. (And poor ` stays pathetically hard to see, even harder than '.)

I prefer the FC5 default background; the new one is too dim and dark for my tastes. The FC5 one may have been relatively monochromatic, but at least it wasn't dark. The login screen is especially dark and makes me feel like I'm entering a cave (given the decorations, possibly one out of a video game).

The ATI X300 I have in the current test machine finally has hardware accelerated 3D and DRI (the website says that everything through the X850 based stuff should, but I haven't confirmed that in person yet). Compiz works fine, although on an upgrade one needs to remember to do 'yum install compiz' to have it available. Mind you, some of the default effects are more glitzy than good; I recommend turning off the optional settings in System → Preferences → Desktop Effects.

Sidebar: fixing the wrong number of RAID disks in a software RAID-1

If you have accidentally created a RAID-1 array with two real drives and one spare drive by doing:

mdadm -C /dev/md0 -l 1 -n 3 /dev/foo /dev/bar missing

instead of:

mdadm -C /dev/md0 -l 1 -n 2 -x 1 /dev/foo /dev/bar missing

(like I did), the solution is pretty simple:

mdadm --grow --raid-disks=2 /dev/md0

This can safely be done to a live software RAID device.

I have to dock Anaconda points for not telling me why it was not bringing up my RAID devices, especially if it is going to later bomb out because it can't mount partitions that are using them and is going to 'corrupt' my LVM configuration when I finally get things going. A warning would have saved me a lot of time and a certain amount of heart attacks.


Comments on this page:

From 24.98.83.96 at 2006-10-30 21:03:33:

Does 'yum check-update' work on your FC6 box? I am getting errors each time I run it, and I can't seem to find much data in the forums to indicate what is causing it (i.e., a bug or slow mirrors).

- Ryan

By cks at 2006-10-30 23:49:46:

I tried it just now and 'yum check-update' (and various related things) were working fine and delivered a pile of updates. However, sometimes I've seen messages about checksum errors and trying other mirrors, and I saw that this afternoon. My assumption to date has been that this happens when the mirrors are partway through pulling in an update, and it'll go away if I give it some time.

(Yum has so-so error handling; many of the error messages I've seen have been too low-level and terse to be really helpful.)

By cks at 2006-10-31 00:34:46:

For a resource on other FC6 issues, the Fedora Project Wiki has a Common Bugs and Known Issues page.

Another little annoyance of the upgrade is cleaning up the RPMs that were migrated from i386 versions to x86_64 versions between FC5 and FC6. The update process does not see these as updates that should remove the old version (it can't; that would clash with multiarch support), so I get to do this by hand. The big source is OpenOffice, but there seem to be others.

(I noticed these via the package-cleanup program that's part of the yum-utils RPM. Unfortunately it doesn't generally report the architecture of packages with problems, so one gets to dig around a bit.)

Written on 30 October 2006.
« Python's assert is a weak debugging tool
A brief Exim observation »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Oct 30 17:41:34 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.