On Friday, I ducked out of work early to go kayaking because I’d been kept late for various emergencies on previous days. I have been a little worried about the “NO TRESPASSING” and “AUTHORIZED VEHICLES ONLY” signs that have appeared at my put-in at Browncroft Avenue, so I was planning to go down to BayCreek and put in there, but the wind was blowing so strongly that I decided I’d risk the parking ticket and put-in on the more sheltered part of the creek.
Continue reading “Kingfisher patrol”
Category: Revelation
Some upgrades are easier that others
I just upgraded my blog software from 2.1 to 2.2.1. I’ve been wanting to do that for a while, but I wanted some free time. Once again, I ignored the bit in the instructions where it says to deactivate all the plugins first and then reactivate them afterwards, and once again the upgrade worked perfectly. Ok, I had to re-activate the options to get the category and archive widgets as dropdowns, but that was simple.
Small steps
I got the UPS monitoring working by adding the following line to my /etc/sysconfig/ups:
OPTIONS=”-a evolution”
I logged a bugzilla bug for the problems I’m having with “at” and “batch”.
So far so good
The upgrade went as well as can be expected.
The libata business didn’t cause too much trouble. Most of the entries in /etc/fstab used labels rather than device names, so I only had to fix the entries for the swap space and the CD-ROM and DVD burner. I had to fix some entries in /etc/munin/plugins.
Postgres stubbornly refuses to upgrade as always, so I’m going to have to blow the data files away and restore from last night’s nightly backup.
The nightly backup ran twice for some reason, but that might be because I rebooted sometime around midnight. Unfortunately the two runs kind of stepped on each other so I’m running it again now.
NUT (the UPS tools) fails with some problem with a missing file.
I had to uninstall bind-utils for some reason, and now I can’t reinstall it because bind-libs is 9.4.1.-5.fc7 but bind-utils requires 9.4.1.-4.fc7. Hopefully somebody on the Fedora Project will fix that little stupidity. Oh what do you know, it’s fixed now.
Another yum dependency issue I was having last night with “yum groupupdate Base” also seems to have fixed itself this morning.
My Sun JDK rpm got uninstalled somehow.
I had to re-install rawdog (with “python setup.py install”).
I can’t understand why files that I never touch in the fonts area end up getting new identical copies as .rpmnew files. RPM should be smarter about that.
So, not too much to fix. And in return, X is working again, I’m not stuck on an obsolete version of Fedora, and maybe I’ll start getting updates again.
One of these days I’m hoping to move to something Debian based so these upgrades will be less painful.
Wish me luck
I’ve decided it’s time to upgrade my home server from Fedora Core 5 to Fedora Core 7. I tried upgrading from the DVD, and for some reason it was complaining about a lack of partition table on /dev/sda and /dev/sdc. It appears that it was mapping my current /dev/hdg as /dev/sda, and my current /dev/hda as /dev/sdb. That’s a result of libata, but I’m baffled why it mapped hdg before hda, and why that caused the upgrade to abort.
So anyway, I’ve decided to try another “upgrade by yum”. I didn’t want to do that, because ever since the last “upgrade by yum”, I haven’t been able to get X working – I figured a DVD upgrade would fix up any missing stuff.
I had to remove a couple of packages (up2date, rhnlib, pflog-summ, etc) to make the “yum upgrade” stop complaining about dependencies. Currently it’s installing package 802 out of 1297.
Can’t wait to see how hard it will be to fix the various problems to do with libata.