recent upgrade caused me problems

[D. Hugh Redelmeier]

Since the list is not full of complaints, my problem is probably
unique.  But I want to share it anyway.

My system is an HP Pavilion a1250n.  An AMD Athlon 64 X2 3800+ CPU.
It is running Fedora Core 6 for x86_64 with no proprietary drivers.

I update it once in a while.  My problem started when I updated on May
12 (the previous update was on April 3).

Digression, I think: between the two updates, I experienced a kernel bug that
I avoided by turning off irqbalancing
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399#c64

On May 12, I did a "yum update".
My machine froze in the middle of it.  Not only was the console
non-responsive, the machine would not respond to pings.

Finishing the update was tricky.  The packages installed were wedged
in a dependency way.  This makes sense: not all intermediate steps in
a yum update need to be consistent from a dependency viewpoint.  But
it does make it hard to move forward (or backward) after a crash.
Certainly "yum update" would not do the job.  I had to figure out what
to blow away with "rpm -e --nodeps".

==> This is not easy for ordinary users.  Something Should Be Done
    (but I don't have a proposal).

I was nervous that some packages might be busted, so I tried to use
rpm --verify.  Many problems.

A lot of files are rudely shared between i386 and x86_64 variants of a
package, even when these packages are intended to coexist on a
multilib system.  Even if the file contents and permissions are
identical (the benign case that is expected), the timestamps are
different so "rpm --verify" whines.  Best to use --nomtime to ignore
timestamps.

==> Fedora should harmonize packages that are supposed to co-exist and
    "share" copies of files.  The timestamps should be made to match.
    I can imagine a postprocess to do that.

"rpm --verify" seems to be somewhat confounded by prelinking.  I don't
understand how, but I get a shower of messages like this:
prelink: /usr/lib64/evolution/2.8/libeutil.so.0.0.0: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/lib64/evolution/2.8/libeutil.so.0.0.0

==> something should be done to allow verify to work better with prelink.
    Something better than just ignoring files that are subject to prelink.

The default format for "rpm --query" does not show the arch.  This is
very confusing on multilib systems.

==> "rpm --query", at least on multilib systems, should be
    --queryformat '%{name}-%{version}-%{release}.%{arch}\n'
    If this breaks anything, that thing ought to get fixed.

Surprisingly, some packages that were installed in both i386 and
x86_64 forms "shared" files that were different.  This seems like a
bug.  And it gets "rpm --verify" upset.  [This turns out to be wrong
but it should be right.  See later.]  For example, two versions of
ghostscript-8.15.4-1.fc6 are installed and they fight over the
contents of /usr/bin/gs.

==> packages in a multiarch system that are meant to coexist should
    have only identical files at the same path.

It is even worse that this.  As I prepared this message, I found a
problem with too many ghostscripts:

    # rpm -qf --queryformat '%{name}-%{version}-%{release}.%{arch}\n' /usr/bin/gs
    ghostscript-8.15.3-4.fc6.i386
    ghostscript-8.15.3-4.fc6.x86_64
    ghostscript-8.15.4-1.fc6.x86_64
    ghostscript-8.15.4-1.fc6.i386

I guess that the crashed update must have installed the new versions
of ghostscript but did not get around to removing the old.  And
neither did the subsequent "yum update".

==> should "yum update" notice conflicting versions of a package and
    try to fix this?  If not, is there a procedure that a user can
    follow to discover and fix these problems?

So I did an "rpm -e" on the older versions.  Now "rpm --verify"
complains that a bunch of files belonging to the current version of
ghostscript are missing!  So removing an old package breaks the
new package.  Yikes.  But not all files.  So this is a mystery.  For
example, the directory /usr/share/doc/ghostscript-8.15 is now gone but
/usr/share/ghostscript/8.15/lib/Fontmap isn't.  This is not just wrong
but wrong in a non-obvious way.

==> removing an old package should not delete things that belong (or
    are shared with) a package that is not being removed.

I was surprised to find that "rpm -F --replacepkgs" to reinstall the
latest ghostscript packages was a no-op.  It didn't fix anything.
Using "rpm -U --replacepkgs" did work.  The rpm(8) description of -U
and -Fdoes not say anything that would lead me to predict this.

==> this kind of stuff ought to be explained in rpm(8)

After this, "rpm --verify --nomtime ghostscript-8.15.4-1.fc6.i386"
reported no problems.  Yet /usr/bin/gs is part of it and is occupied
by an x86-64 binary.  What is going on here?  I'd call this a false
negative.


And now for something completely different.  An indication that my
Fedora install is broken:

Every once in a while, my system now locks up (since the failed
update).  One or more times a day.  Just like it did during the
update: the system won't even respond to ping.  (Of course there are
few symptoms from the lockups so there is no way to know if they are
the same as the lockup during update.)

I tried several Fedora kernels, even ones that had worked before.  I
still got lockups.

I *don't* get lockups when I run Fedora Xen kernels!  I also get more
power usage since the Xen kernel cannot reduce the CPU clock speed.  I
know that it uses more power because my CPU fan gets noisy once in a
while even when my system is idle.

Since I have not seen any reports of this problem, I guess that this
is a legacy of my particular crashed update.

==> is there a simple procedure to recover from the fallout of a
    crashed "yum update"?

My current thought is to hold out for a few days and move to a fresh
install of FC7.

If my machine had a serial port, I might have looked into enabling a
serial console to see if there were an interesting panic report.

==> is there something like a serial console for modern machines
    without serial ports?  Logging through USB or a network interface
    require rather more of the kernel to be functioning than logging
    through a serial port.