Fedora 14 yum upgrade notes

It is mid November of 2010 and Fedora 14 has been out for about 2 weeks. We have our local mirror all loaded up, so I am ready to upgrade my system (an x86_64 system running an up to date Fedora 13 install).

As usual, my plan is to do the upgrade via yum, and follow my yum upgrade notes for Fedora 13 as a guide.

Backup vital things

As always, I do a backup of vital files. I cannot remember using any of this stuff (perhaps the etc tarball), but it makes me feel better.
cd /root
mkdir -p upgr_f13-f14
cd  upgr_f13-f14
# gather info for potential recovery later
tar -C / -czf etc.tgz etc
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort > rpm.ls
chkconfig --list > chkconfig.ls
ifconfig > ifconfig
route -n > route-n
df -h > df-h
cp -p /boot/grub/grub.conf grub.conf

Switch repositories and launch the upgrade

I copy all the old .repo files (for F13) into /etc/yum.repos.d/F13 as I have always done (though this has never proven to be useful).

Then I pull in the fedora-release rpm (fedora-release-14-1.noarch.rpm) using the following commands:

yum clean all
rpm -Uhv http://mmt/fedora/releases/14/Fedora/x86_64/os/Packages/fedora-release-14-1.noarch.rpm

Next, I set aside our custom repository (which has not yet been built for Fedora 14) via:

cd /etc/yum.repos.d
mkdir FC14
mv mmt.repo FC14

I used to explictly try to update rpm and yum before updating everything else via the command yum update rpm\* yum\* . However, this tends to try to pull in hundreds of packages due to all the dependencies involved, so I no longer do this.

I have found that I must again do the yum clean all, or else the global update will claim there are no packages to update. So, to go for broke, I do this:

yum clean all
yum -y update

Straighten out package dependencies

There is always some of this. There are several old (F11 and F12) packages with odd dependencies. I just erase the offending old packages and try again.
yum erase kudzu alchemist rhpl python-pyraf system-config-display
yum -y update
In the past, this has sometimes required multiple iterations of the "rinse - lather - repeat" style, but not this time.
The summary of what will be done is:
Install     130 Package(s)
Upgrade    1840 Package(s)
Remove        2 Package(s)
I get some warning about rpmfusion repository keys, and then the update stalls because of:

Problems with VirtualBox

There is some issue with GPG keys for VirtualBox. It claims that I have keys installed that are incorrect. Just moving the repo file off to the side is insufficient, there is also some dependency problem with python(abi), so I must remove the package itself, hoping this won't wipe out my Virtual Machine which contains Windows. (It turns out that it does not, see below)
What I do is:
cd /etc/yum.repos.d
mv VirtualBox.repo FC14
yum erase VirtualBox-3.2
yum -y update
This business with bad keys may be due to the Sun to Oracle transition, but I have had trouble with Virtual Box RPM updates before.

The update process

This does the trick and the update is off to the races. A number of packages yield rpmnew files for config files:
/etc/shadow
/etc/named.conf
/etc/ntp.conf
/etc/httpd/conf/httpd.conf

A number of openoffice packages give inscrutable errors that look like this:

  Updating       : openoffice.org-voikko-3.1.2-1.fc14.x86_64

  ERROR: Error while adding: vnd.sun.star.expand:$UNO_SHARED_PACKAGES_CACHE/uno_packages/66xZYj_/voikko.uno.pkg
         Cause: general error during transfer
I get similar errors for:
openoffice.org-ooolatex-4.0.0-0.8.beta2.fc14.1.x86_64
openoffice.org-writer2xhtml-1.0.2-3.fc14.x86_64
openoffice.org-extendedPDF-1.4-10.fc14.x86_64

This funky warning comes up:

Warning in file "/usr/share/applications/gnome-nautilus-folder-handler.desktop": usage of MIME type "x-directory/normal" is discouraged ("x-directory" is an old media type that should be replaced with a modern equivalent)
I don't know why whoever maintains whatever package this file belongs to doesn't fix this, but I won't worry about it. I am just bored waiting for the update to finish and making notes in this file.

Doing the update over a 100 Mbit LAN from a fast local server takes about 2.5 hours.

Reboot

The reboot is straightforward and I am up and running Fedora 14. All in all, a very clean and straightforward upgrade.

Cleaning up

I try to reinstall the packages I had to delete because of dependency problems:

Firefox and Flash

Finally, Adobe Labs has provided a new flash plugin for 64 bit Firefox. For a long time I have been running an old flash plugin for 64 bit which Adobe no longer provides and that Firefox complains about. As of 9-27-2010 there is a new plugin for 64 bit linux from Adobe Labs, it downloads as:
flashplayer_square_p2_64bit_linux_092710.tar.gz
I now need to repackage it as an RPM and add it to our local yum repository.

To find out what version of flash you are running, just access the "about flash" page at this link. The 9-27-2010 prerelease of the "square" plugin is 10.2.161.23.

dkms

In preparation for the installation of Virtual Box, and based on some coaching at the virtual box website, I install the dkms package:
yum install dkms
Apparently dkms is a package that allows kernel modules (which for virtual box are vboxdrv, vboxnetflt and vboxnetadp) to be properly updated when linux kernel updates come along, which sounds like a good thing.

Virtual Box

I go to the Virtual Box Linux Downloads site and download the oracle public key and the RPM for Fedora (and they have an RPM specific to Fedora 14 and AMD64).
I download the following two files:
oracle_vbox.asc
VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm

I then do the following: issue the command:
rpm --import oracle_vbox.asc
rpm -Uvh VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm 
This yields the following:
[root]# rpm -Uvh VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:VirtualBox-3.2         ########################################### [100%]

Creating group 'vboxusers'. VM users must be member of that group!

No precompiled module for this kernel found -- trying to build one. Messages
emitted during module compilation will be logged to /var/log/vbox-install.log.

Stopping VirtualBox kernel modules                         [  OK  ]
Uninstalling old VirtualBox DKMS kernel modules            [  OK  ]
Trying to register the VirtualBox kernel modules using DKMS[  OK  ]
Starting VirtualBox kernel modules                         [  OK  ]
[root] rpm --checksig VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm 
VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm: (sha1) dsa sha1 md5 gpg OK

Note that the name of the package is "VirtualBox-3.2".

Now under the Applications menu, I find Virtual Box at:

   Applications->System Tools-> Oracle VM Virtual Box
I can now start up my old Windows XP virtual machine just fine!

Python-pyraf issue

I had to remove this package to do the upgrade, now when I try to reinstall it, I get the following:
[root]# yum install python-pyraf
Loaded plugins: downloadonly, verify
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package python-pyraf.x86_64 0:2.8-3.fc11_tep set to be installed
--> Processing Dependency: python(abi) = 2.6 for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Processing Dependency: python-abi = 2.6 for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Processing Dependency: libpython2.6.so.1.0()(64bit) for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Finished Dependency Resolution
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: libpython2.6.so.1.0()(64bit)
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: python-abi = 2.6
           Installed: python-2.7-8.fc14.1.i686 (@fedora)
               python-abi = 2.7
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: python(abi) = 2.6
           Installed: python-2.7-8.fc14.1.i686 (@fedora)
               python(abi) = 2.7
           Available: python3-3.1.2-14.fc14.i686 (fedora)
               python(abi) = 3.1
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
It turns out that the dependency on python-abi=2.6 is a fiction of sorts. What is going on is that under Fedora 13, we were running python 2.6.4, and now under Fedora 14, we are running python version 2.7. This package was built to run with python 2.6, and will need to be rebuilt for 2.7 and any changes in the ABI (Application Binary Interface) will need to be sorted out. Notice also that python 3 is available under Fedora 14. Also note that pyraf itself has moved along to version 1.9 as of May, 2010.
Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org