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
for a in $(find /etc /var -name '*.rpm?*'); do echo $a; doneWhat 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 --orphansThe 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.noarchThe 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.i386Maybe the hal package can be cleaned up after I do the fc10 upgrade?
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.
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:
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".
(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.
Adventures in Computing / [email protected]