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.
