Partial FC6 upgrade?

[Jim Cornette]

Tony Nelson wrote:
> At 1:26 PM -0500 11/11/06, Tony Nelson wrote:

>>> I'll create a bugzilla report and post the ID.
>> bz 215127, which I've added to.
> 
> It appears that the problem was due to a (slightly) corrupt RPM database,
> as, after blowing up the database doing a "yum remove" of a suspicious
> package (duplicate?  forget which package now) and then rebuilding the
> database, an upgrade succeeded.

I've had this problem too with rawhide as well as a locking problem in 
FC6 once. The FC6 problem updated correctly, the database checked out 
and the next install was OK.
The development one got so bad that the terminal characters were not 
even close to the standard 26 character alphabet, I had to remove the 
__db.* files and follow-up with an 'rpm --rebuilddb'

I'm thinking the problem might be from the puplet interfering with 
ongoing transactions which is killing the rpm databases. This is a WAG 
so I really will have to disable the puplet applet and note if database 
corruption is ongoing or not present any longer.
On the development version, only one package entry was corrupted and 
segfaulted before rebuilding the rpm database. I tried a lot of things 
to remove, upgrade the packages and was led to believe by supposition 
and mail traffic that running rpm -qaV with no errors would let you know 
if everything was intact within the database. This is however not true. 
The segfaulting entry which queried alright means the rpmdb is a bit 
more complex than just recording what packages are installed.

> 
> Also, I had only noticed Anaconda's logs in /var/log/anaconda*, and not the
> ones in /root/upgrade.log*, which had many error messages in them.  Still,
> it would be nice if Anaconda mentioned that the upgrade had failed at the
> end, instead of looking normal with no errors displayed.

The information would be nice to know. I wonder why it does not? It asks 
for you to reboot on certain phases, so a automatic warning message post 
install or an option to look at the install log after installation was 
completed would be valuable information.

Jim

-- 
DOS: n., A small annoying boot virus that causes random spontaneous
system crashes, usually just before saving a massive project. Easily
cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS.
(from David Vicker's .plan)