Installing Fedora Core 3, Part 2

NTFS support

I had a bunch of old files that I put on two hard drives in my system that I wasn’t installing Fedora onto. I assumed that read-only access would be built-in to whatever Fedora version I installed. I was wrong. Maybe I missed a checkbox? I found a site which explains how to recompile the kernel to provide NTFS support. It was a bit of a hassle, but I did it. One interesting caveat is that there is no longer a separate kernel source package, you need to download the regular kernel package, but specify that you want the source for it, like you can with any package. I did this. It was nice to compile a kernel optimized for my particular processor. Of course, then my NVIDIA driver refused to work with the new kernel. And up2date complained and said that since I was using my own kernel I wouldn’t be able to apply any Fedora security patches. I ended up just copying over the files from my old NTFS partitions to the new ext3 partitions, and then rebooting back to the Fedora stock kernel, so that my video drivers would work, and up2date would stop complaining. I don’t have a dual-boot system, so I’m going to re-format those drives to ext3 anyway.

Gnome and KDE:

I’ve always used Gnome as my desktop, just because it’s always the default, and the Linux boxes at work always have it. Like a hot girl who is tempting but bad news, I’ve always found that Gnome is pretty but annoying. I use KDE now that I’ve had time to experiment with both of them, and I’ve found that it is easy to make it behave exactly as I want it to. It’s not quite as pretty as Gnome, but the recent KDE version is very nearly as easy on the eyes as Gnome.

NVIDIA driver

I have an NVIDIA card, and decided to take advantage of its native Linux driver. I installed it fine. It didn’t have a module pre-built for the 2.6 kernel that I’m running, but it managed to compile itself for my kernel without a hitch. Great. When I rebooted, however, it refused to start my X server. What the–? The problem, I found, was that udev, the Linux hot-plugging system, was removing the /dev/nvidia* drivers on shutdown, and wasn’t getting them put back in time for the X server to start up again. The solution? “cp -a /dev/nvidia* /etc/udev/devices/” [Ref] This puts the nvidia drivers into /dev at boot no matter what. There is a separate problem with file permissions getting removed from the NVIDIA drivers in /dev. This prevents any OpenGL program from working. All of these driver files start out as being readable and writable by everyone. It seems that the PAM security module is changing their permissions on login or logout. NVIDIA claims that by removing all references to “/nvidia” in /etc/security/console.perms, you can prevent this from happening. I did exactly what they said, but sometimes I still see that the permissions have been changed. I don’t know which mechanism is causing this to happen. It remains an open issue. What I do to make it work is to su and add permissions by hand each time. It’s a bit annoying. If you see random core. files in your home directory and you didn’t see any program crash, you might check that your OpenGL screensavers are working. If not, they can leave those core files behind.

Booting in text mode:

One of the things you find when your video driver keeps breaking, is that the new Fedora relies heavily on advanced hi-res video modes and proper functioning of the X server very early in the boot process. If there is a problem with your X video driver, this makes the screen cease to give useful information very early on when you’re booting. The solution to this is to remove the kernel parameter “rhgb” to force boot to happen only in text mode without X. Then you’ll be able to see what’s going on, even if your X configuration isn’t working. You may also want to remove the kernel parameter “quiet” to see even more diagnostic info. While booting with grub, press any key before boot starts to get into the grub menu, cursor so your kernel entry of choice is highlighted, press ‘e’ for edit. Then you can delete these kernel parameters. Don’t worry, the changes are not permanent–they only affect the current boot. If you really have an emergency, you can put the kernel parameter “single” at the end to boot into single-user mode, which automatically boots as root into runlevel 3 with no X server.

MP3 support

Fedora takes a purist line that mp3 files taint the kernel because they use a patented file format. This is really annoying. Not only do none of the sound-playing programs included with Fedora play mp3s, but the ones that do play mp3s in their normal state have had that capability systematically ripped out of them by the Fedora people. In fact, KDE plug-ins natively have mp3-playing capability that in Fedora has been removed. I can download individual programs no problem, but recompiling KDE from scratch is an enormous pain. The easiest fix is to download an rpm for xmms that adds mp3 capability. The other programs and KDE modules will have to be re-installed with their un-mangled versions.

Mozilla applications:

The Mozilla applications that I use, Firefox and Thunderbird, were thoughtfully included in the Fedora list of packages. Unfortunately they were the previous versions, but Firefox 1.0 was quickly added as an up2date upgrade, even though I was stuck with Thunderbird 0.8 when 0.9 had been released a few weeks ago. What I didn’t realize at first, but soon did, was that they were custom versions that had been hacked by the Fedora people. Certain things, like the file dialogs, were obviously different from the stock Mozilla widgets. In fact, Firefox 1.0 from Fedora was really slow and kept crashing. Not only that, but it didn’t have the Talkback crash feedback feature installed, presumably because that violated the Fedora people’s open-source sensibility by being not free source. So every time the buggy Fedora Firefox crashed, I couldn’t even send crash data back to Mozilla. To remedy the situation, I removed the Fedora packages of Firefox and Thunderbird from my package list, and downloaded the most recent versions from www.mozilla.org. They now run beautifully fast and stable, and I can enable all the features (including Talkback and the DOM inspector) that I want. Update: an admin at the mozillazine.org forums said he ran the stock Fedora Firefox 1.0 with no problems. Maybe he had a faster computer? Less prone to getting confused in processing? I don’t know, but I’m not going back.

yum and up2date mirrors

When you first install Fedora, running yum to install new packages or up2date for updates involves a veritable Wheel of Fortune of mirror sites. The stock mirror sites that are specified for both tools can be anywhere in the world, functional or non-functional. They can make you wait a long time for no real reason, when a perfectly good mirror may be down the road. You should change your configurations so that they point only to local mirrors. Do this for yum. Do this for up2date. (Edit /etc/sysconfig/rhn/sources.) [Ref]

Give your computer a name!:

I edited /etc/sysconfig/network to give my computer a more interesting name than “localhost.localdomain”.