Fedora Core 10 upgrade notes

Backup vital things

I have been running Fedora Core 9 since late 2008 (it is now May of 2009). I just introduced a massive set of FC9 updates, which has broken the flash plugin for firefox 3. Rather than sort all this out and then upgrade to FC10, I am going to upgrade to Core 10, then sort it all out. I plan to do the upgrade via yum. A wise man would start on this early in the morning and expect this to consume an entire day. I did not do this and ended up leaving the office at 11:00 PM.

I ran across one fellows notes, which included some "cover your butt" backup of crucial information as follows, seems like wisdom and prudence:

mkdir -p /root/upgrade/f9-f10
cd  /root/upgrade/f9-f10
# gather info for potential recovery later
tar -C / -czf etc.tgz etc
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort > rpm.ls.f9
chkconfig --list > chkconfig.ls.f9
ifconfig > ifconfig
route -n > route-n
df -h > df-h
cp -p /boot/grub/grub.conf grub.conf.f9

Cleanup bogus and ancient packages

The fedora wiki recommends that you tidy up your system prior to the upgrade (I know I have some old fc8 packages laying around, so this will be good.
for a in $(find /etc /var -name '*.rpm?*'); do echo $a; done
What I do here is to painfully hand merge changes for files that I know I have hand tweaked, then for files I know I never messed with, I just overwrite with the rpmnew file. Then repeat the above script till clean. After this, these two commands will point out possible trouble spots:
package-cleanup --leaves
package-cleanup --orphans
The first of the above lists dozens of libraries (all fc9) that I am just going to leave alone. The second gives the following nice short list. I try to yum erase all the fc8 packages, I also can get rid of the livna package (this is now renamed rpmfusion).
VMwareWorkstation-5.5.5-56455.i386
chkfontpath-1.10.1-2.fc8.x86_64
grub-0.97-33.1.fc8.x86_64
hal-info-20080607-2.fc8.noarch
kernel-2.6.27.5-41.fc9.x86_64
kernel-devel-2.6.27.5-41.fc9.x86_64
livna-release-1-1.noarch
tcl-html-8.4.17-1.fc8.x86_64
xephem-3.7.3-2.i386
xorg-x11-drv-via-0.2.2-4.fc8.x86_64
xorg-x11-fonts-truetype-7.2-3.fc8.noarch
The hal-info package is oddly required by the fc9 version of the same, so I cannot get rid of it (or so it seems).

When I am done, I am left with the following orphans (which I think I installed from rpms rather than via yum, except the packages for the kernel prior to the one that I am currently running.

VMwareWorkstation-5.5.5-56455.i386
hal-info-20080607-2.fc8.noarch
kernel-2.6.27.5-41.fc9.x86_64
kernel-devel-2.6.27.5-41.fc9.x86_64
xephem-3.7.3-2.i386
Maybe the hal package can be cleaned up after I do the fc10 upgrade?

Switch repositories and do the upgrade

I move all the .repo files (for FC9) into /etc/yum.repos.d/FC9 - then I pull in the rpm with the new repos
yum clean all
rpm -Uhv ftp://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/x86_64/os/Packages/fedora-release-*.noarch.rpm
yum update rpm\* yum\*
The update of yum and rpm does pull in 16 new packages or so.
I hand edit fedora.repo and fedora-updates.repo to use our local mirror.
Then, as recommended, I get out of the graphical environment and do the upgrade as follows:
Ctrl-Alt-F2
login as root
telinit 3
yum upgrade

A number of issues come up (dependencies and conflicts between i386 and x86_64 versions). I solve them by removing the following packages:

yum erase transcode
yum erase pango-devel.i386
yum erase dmraid.i386
yum erase wireshark.i386
yum erase isdn4k-utils.i386

With the exception of transcode (that has some screwy dependence on image magick), these are packages that I cannot really imagine why I would want both i386 and x86_64 versions. Transcode is for fiddling with video and audio codecs, part of an effort to copy a DVD a friend burned of some home movies long ago. I can always reinstall it later if that is something I want to pursue further.

After this, it announces that it will install 129 new packages, and update 1522, transfering 1.5G in the process. The transfer takes 111 minutes in and of itself, and it is on into the late of the night till my system is up again. A wise man would start on this early in the morning and expect this to consume an entire day.

I always see packages flying by and wonder what the heck they are, here are a few:

Post install cleanup

I hand inspect and merge some rpmnew files (/etc/group.rpmnew and named.conf.rpmnew). Also /etc/mail/sendmail.cf and /etc/httpd/conf/httpd.conf.

DNS was whacked

My machine is set up to be a caching nameserver, but my resolv.conf apparently got overwritten (or something), so I ignored the notice about network manager overwriting the file and set up resolv.conf by hand. We will see if network manager needs to be beaten with a pipe as usual.

Odd cron/sendmail trouble

I am now getting a strange message when one of my cron jobs tries to send me email:
WARNING: RunAsUser for MSP ignored, check group ids (egid=10, want=51)
can not chdir(/var/spool/clientmqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.
Group 51 is smmsp, the group owner of the clientmqueue directory, but 10 is "wheel".

Firefox and 64 bit flash plugin problem

This is busted now (but java is working, so that is something). I used to have this working, honest I did, and with a 64 bit browser (maybe). I still think the best solution is to run a 32 bit firefox (though it is the devil to get yum to deliver this to a 64 bit install, but it can be done -- or just force it in straight from the rpm).

sendmail, dns, and mailman

I found myself in some odd situation where I was receiving mail just fine, but no mail was going out. Lots of things were piling up in /var/spool/mqueue and the mailq command would show
	(host map: lookup (xxxxx): deferred)
The log file (/var/log/maillog) showed stat=queued.

This took a long time to figure out. The bottom line answer was to restart sendmail. After I did the upgrade (and when sendmail first started), my DNS was completely screwed up (which I fixed by hand crafting the /etc/resolv.conf file). Apparently sendmail was keeping its own ideas about the DNS situation and needed a restart after I fixed the resolver. After restarting sendmail, most but not all of the queued mail went out, then hand running sendmail -v -q sent the rest.


Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org