Fedora Core 9 notes

It is late October of 2008. I am told that Core 10 is in the wings and finally have some free time, so here goes with Core 9.

I did a full up install on my home machine, with only one major issue (see below). My machine at work has lots of "tailoring", so it is by far more sensible to use the YUM upgrade process. For some reason, the fedora "official policy" is to deprecate this. My experience has been that if you don't do something crazy like try to do a yum upgrade from some ancient system like Core 5 all the way to Core 9, it will go smoothly. We shall see.

Getting Ready

The first thing is to make sure my Core 8 system is up to date (and tidy). 
yum clean all
yum update
Since I have been keeping my system up to date, this finds nothing to do, and no bizarre conflicts. This is good.

Next I look for rpmsave and rpmnew files in /etc/ and /var using this ruby script. Most of the time (I have found) the rpmnew file matches the file it supposedly updates and can just be removed (or renamed to preserve the modification time), this script takes care of that. Most of those that differ are just new versions of files that I never customized and can just be moved into place. Those that I have customized must be merged by hand.

package-cleanup

There is a new "thingie" called package-cleanup, that is part of yum-utils. I needed to get the yum-utils package as follows: 
	yum install yum-utils
After this, you can find unused and orphaned packages via: 
	package-cleanup --orphans
	package-cleanup --leaves
Many of the orphan packages (on my system) are things I have installed by hand (as rpms) and want to keep, but not all, this turns up some dead wood that I do want to pitch overboard. Such as: 
	rpm -e tux
	yum erase krbafs
	yum erase pgplot*
	yum erase nspluginwrapper-i386
	yum erase perl-Astro
The "leaves" packages turn up an extensive list of fc8 libraries that I am not going to mess with.

After all this, I do: 

	yum list extras
And it lists all the orphan packages that I already decided to keep.

Last of all, I do this: 

    rpm -qa --last > zzz
The tail end of this file is an extensive list of packages with fc7 markings that I definitely should consider eliminating (and/or getting later versions of). This is actually quite handy.

Switching repositories

We keep a local fedora mirror so that we don't have to hammer the official mirror sites (well, we hammer then once and that is it). I can access this via: 
/net/mmt/media/mirrors/fedora

A quick look at /etc/yum.repo.d shows me that very little here needs to be changed, most everything depends on $releasever. I am tempted to hand edit files here, but resist the temptation and do this the recommended way, which is as follows: 

cd /net/mmt/media/mirrors/fedora/releases/9/Fedora/x86_64/os/Packages
rpm -Uvh fedora-release-*.noarch.rpm
At this time, this gets me: Also, I get the message: 
warning: /etc/yum.repos.d/fedora-development.repo saved as /etc/yum.repos.d/fedora-development.repo.rpmsave
It looks like the development repository is long gone (and maybe has been for some time). 
rpm -qlp fedora-release-notes-9.0.0-1.noarch.rpm
Tells me where the release notes go (looks like /usr/share/doc/HTML/release-notes. 
rpm -qlp fedora-release-9-2.noarch.rpm
Is quite instructive. It puts things in /etc/yum.repos.d, /etc/system-release, as well as /usr/share/fedora-release/README and other places.

Go for broke!!!

yum update
This gets off to a faltering start, then trips over: 
http://mmto.org/fedora/updates/9/x86_64/repodata/filelists.sqlite.bz2: [Errno -1] Metadata file does not match checksum
The answer to this is to do: 
yum clean all
Yes I did this once at the start of things, but apparently doing some of the pruning with yum erase brought some stuff back into the yum cache that is inconsistent with the FC9 repositories. Apparently it is crucial to do the yum clean all after bringing in the FC9 release rpm.

Also, before trying the full update it is a good idea to upgrade crucial packages (or so folks say) such as: 

yum update rpm
yum update yum

Now we get a lot further, but then the update blows up with a long list of missing dependencies (all libraries that are needed by various packages), such as: 

Error: Missing Dependency: libcrypto.so.6()(64bit) is needed by package php-5.2.6-2.fc8.x86_64 (installed)
Error: Missing Dependency: libssl.so.6()(64bit) is needed by package ruby-libs-1.8.6.287-2.fc8.x86_64 (installed)
There are at least two contributors to this mess. One is that I am using the original release rpm: rpm -qlp fedora-release-9-2.noarch.rpm and should be using the new one (from updates), namely: fedora-release-9-5.transition.noarch. The other is that I moved livna.repo out of the way in the midst of some thrashing around trying to sort out some other things. After making these changes, I have dependency issues that I can solve by discarding 3 packages:

After this it gets to be a game. You type yum upgrade, it downloads a zillion packages, then spends 10 to 15 minutes doing a transaction check, then announces some conflict. Then you remove some package (making a note to install it again later ... maybe). Then you rinse, lather, repeat till you get lucky and it launches into the upgrade.

The packages I needed to remove were:

There was a strange business along the way where it was eager to remove curl, but that was going to take yum with it. Then I tried yum upgrade curl and it found the conflict with dhclient. After that the full yum upgrade took off, and I never did need to remove curl.

Moral of the story: keep thrashing around removing packages until you either get lucky or give up and do a fresh install.

The Ugly stuff

Well, there is always something. This time it is: The "fedora team attitude" seems to be that this isn't a problem for them, so why should they be concerned because multitudes of users are affected.
Kind of like big government in action.

32 bit firefox on an x86_64 system

The following link looked like a really easy way to do what the fedora distribution makes it hard to do, namely run a 32 bit firefox on a 64 bit system. However, I got lucky with the plugin wrapper scheme described in the next section and never did this, however it looks simple and straightforward: In case the link evaporates, here is the gist of things:

1 - Create a file /etc/yum.repos.d/fedora-i386.repo as follows: 

[fedora-i386]
name=Fedora $releasever - i386
failovermethod=priority
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/i386/os/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=i386
enabled=1
gpgcheck=1
includepkgs=firefox
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
#
[updates-i386]
name=Fedora $releasever - i386 - Updates
failovermethod=priority
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/i386/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=i386
enabled=1
gpgcheck=1
includepkgs=firefox
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

After this is in place, only 2 commands: 

su
rpm -e firefox.x86_64
yum install firefox.i386

64 bit firefox

What a mess!

If you want a java plugin and/or a flash plugin you are going to be unhappy. I hate java plugins (and java in general), but some sites use them (like the national weather service animation of satellite maps), so they have their benefits. Flash however is getting more and more ubiquitous on the web, so we really do insist on having that. And then there are movie players which I am more or less ignoring at this point, since I don't have working sound, at it looks like I never will under linux, but we are getting off topic.

If you are running a 64 bit system, you can't do like every sensible person did back in Core 8 days and just run the 32 bit firefox and have plugins that work; the default situation is "plugin hell", described in detail in what follows.

One option that has been suggested is to ditch 64 bit Firefox and just run Opera, which is easy to get in 32 bit form and works (I am told) with easy to get plugins.

The other approach seems to be nspluginwrapper, which has the stated purpose of allowing 32 bit plugins to be run by a 64 bit browser. I seem to remember trying this once, just before I threw up my hands and decided 32 bit firefox was the way to go.
The following is claimed to work: 

rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
mkdir -p /usr/lib/mozilla/plugins
yum install nspluginwrapper.{i386,x86_64} pulseaudio-lib.i386
yum install flash-plugin
mozilla-plugin-config -i -g -v
After joyfully finding these instructions, I check my system: 
rpm -qa --last | grep adobe
  adobe-release-i386-1.0-1                      Thu Oct  4 18:19:54 2007
yum list | grep nsplugin
  nspluginwrapper.i386                     1.1.2-2.fc9            updates-newkey  
  nspluginwrapper.x86_64                   1.1.2-2.fc9            updates-newkey  
yum list | grep flash-plugin
  flash-plugin.i386                        10.0.12.36-release     installed
My system already has the adobe-release rpm (from back in 2007, almost exactly a year ago, a hold over from before core 9 days), and we have the other parts too. But there is nothing on my system called mozilla-plugin-config, so what is a mother to do?

A look at /usr/lib/mozilla/plugins shows the following link (which is good): 

libflashplayer.so -> /usr/lib/flash-plugin/libflashplayer.so

Another tip is to get something called ndiswrapper, which can be found in the livna repository (which I already have an entry for in my /etc/yum.repos.d directory, so I do: 

yum install ndiswrapper

This results in 3 packages being installed: 

Downloading Packages:
(1/3): kmod-ndiswrapper-1.53-4.lvn9.2.x86_64.rpm
(2/3): ndiswrapper-1.53-1.lvn9.x86_64.rpm
(3/3): kmod-ndiswrapper-2.6.26.6-79.fc9.x86_64-1.53-4.lvn9.2.x86_64.rpm

Voila! It works (or seems to). My acid test is to visit the Strobist site which has lots of flash stuff inline (which were previously rendering as white boxes).

Heck, even the movie players (left over from my FC8 install) work now on the Strobist site, so this is good.

My approach to the nvidia driver

Back in fc8 days, I gave up on the kmod-nvidia thing from the livna repository. New kernels would come out, then logjam with the dependency on the kmod-nvidia driver (or something like that, the details of which I just don't recall). What I do now is to use the vendor supplied driver source and build it each and every time I boot as follows, by adding the following lines to my rc.local: 
if [ -f /root/NVIDIA.run ]; then
    /root/NVIDIA.run -s -n
fi
The -s says to accept the license and run silently. The -n says to not use any precompiled interfaces (forcing it to recompile each time).

This makes my reboot take a lot longer, but typically I only reboot when a new kernel comes along. Every once in a while it is necessary to revisit the nvidia site and get the latest driver.

There is a -update switch that will visit the nvidia site and check for newer driver versions, but I am not yet brave enough for that.

Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org