Bug 215127 - FC5-FC6 upgrade succeeds, but most packages left unupgraded.
Summary: FC5-FC6 upgrade succeeds, but most packages left unupgraded.
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-11 07:57 UTC by Gilboa Davara
Modified: 2008-04-04 19:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-04 19:54:55 UTC
Type: ---

Attachments (Terms of Use)
Anaconda logs. (1.01 MB, application/x-compressed-tar)
2006-11-11 07:57 UTC, Gilboa Davara
no flags Details
anaconda logs and rpm list from partial FC6 upgrade (79.33 KB, application/x-gzip)
2006-11-11 17:31 UTC, Tony Nelson
no flags Details

Description Gilboa Davara 2006-11-11 07:57:53 UTC
Description of problem:
Two days ago I upgraded my laptop (P2/366, 256MB) from FC5 stock installation
(+livna) to FC6.
AFAICS (at the time) the installation was successfully, no error messages, no
OOPS, nothing.
I restarted the machine - and found a semi-working FC5/FC6 hybrid. (~50% of
packages were FC5, some were FC6. E.g. /etc/issue was FC5)
Sadly enough, I needed the machine in a hurry, and couldn't leave it at its
current state for further diagnostics so I had to reinstall FC6 from scratch.
(Which is working just fine)

By looking at the installation logs it seems that the original RPM (?) DB was
corrupted, but:
A. The FC5 machine -was- working just fine. Install/uninstall packages
B. Why didn't Anaconda detect the error, and -stopped- once all hell broke lose?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install FC5.
2. Install all the updates.
3. Install FC6.
Actual results:
Botched installed.

Expected results:
Working installed.

Additional info:
Attached logs.

Comment 1 Gilboa Davara 2006-11-11 07:57:53 UTC
Created attachment 140956 [details]
Anaconda logs.

Comment 2 Tony Nelson 2006-11-11 17:31:53 UTC
Created attachment 140967 [details]
anaconda logs and rpm list from partial FC6 upgrade

I think I have this issue.  Here are my anaconda logs and rpm lists.  I will
wait until Wednesday 15 Nov until trying again, so if anyone needs more info,
ask before then.

My installation is FC5 upgraded from FC3.  I have two install partitions (LV00
and LV02, LV01 is swap); I upgrade by copying my active installation to the
other partition, getting that working again, and then upgrading via the

I started the install from DVD with: "linux askmethod hda=noprobe hdb=noprobe",
and told it to use the .iso on my C drive (hde1).  When I got to the screen
that would start the upgrade, I backed up, in hopes that that would show the
repo selection screen (gee, is there really no way to select repos during an
upgrade?); when that just took me to the package-finding screen, I gave up and
pressed Next (waiting again) and then Next to start the upgrade.  The upgrade
appeared to succeed, but when I checked my /boot volume to reinstall any
deleted kernels for the FC5 install and grab a new copy of grub stage 1 for
NTLDR, I found that no changes had been made (even though I had chosen to
upgrade grub).	I then rebooted and noticed that it didn't seem quite upgraded.
 Notably, fedora-release still said "Fedora Core release 5 (Bordeaux)".

I rebooted into my original FC5 and mounted the other install.	I see in
/var/log/anaconda.log that what seems like the proper set of packages was
selected (there are 1086 "Adding Package" lines, though some are repeated), but
"rpm -qa --last" on the new install, when compared with the original one, shows
that 151 FC6 packages have been added while no FC5 packages have been removed.

The .iso file has the proper sha1sum, and the DVD verifies with dd'ing it back
in.  I had run memtest86 for 5 passes before upgrading.

Comment 3 Tony Nelson 2006-11-11 17:33:42 UTC
Ehh, forgot to say that my RPM database does not seem to be corrupted, either on
the original install or in the new hybrid.

Comment 4 Tony Nelson 2006-11-15 16:51:30 UTC
OK, Wednesday has arrived and I'm blowing away the odd update.  I did a full
dump of it, so specific files may still be requested if they would help in
debugging this.

Comment 5 Tony Nelson 2006-11-17 02:32:21 UTC
I think the problem is due to a (slightly) corrupt RPM database.  While it
appears to work on my FC5 installation, after re-copying the installation and
getting the copy working again, I tried to yum remove a package that looked
problematic (forget which one) and the RPM database blew up.  I rebuilt the RPM
database, and then upgrading to FC6 succeeded, with nearly all packages
upgraded.  This leads me to suspect that the problem stems from having had a
corrupt RPM database that was still limping along.  Note that this time I also
didn't try backing up from the screen that would start the upgrade.

The logs I posted before were only some of the logs.  Anaconda puts its logs in
/var/log/anaconda* and also in /root/upgrade.log*, and I only noticed the
/var/log/ ones at first.  /root/upgrade.log is huge, and full of db4 errors
telling me to "run database recovery", whatever that is.  You probably don't
want it.  I also have the corrupt RPM database files.

Anaconda should clearly show at the end of installation that the installation
failed and how many packages were not upgraded.  Possibly Anaconda should check
the RPM database for integrity before starting an upgrade, if there is a way to
do it and it isn't too slow.

Comment 6 Gilboa Davara 2006-11-17 06:34:16 UTC
... Or at least, check the RPM database -before- trying to upgrade.
Leaving the machine in an inconsistent state (without telling the user anything
about it) is a big no-no.

- Gilboa

Comment 7 Tony Nelson 2006-11-17 23:53:42 UTC
Pritam Ghanghas on fedora-list suggested using the tools in /usr/lib/rpm/,
especially rpmdb_verify.  I tried the following, and it is fast enough (and
found new corruption, hmm):

cd /var/lib/rpm ; for name in * ; do echo $name ; /usr/lib/rpm/rpmdb_verify
$name ; done

Anaconda could do something slightly more sophisticated (skip any __db* lock
files), and, if there is corruption but the Packages file is OK, offer to
rebuild the database with "rpm --rebuilddb" before proceeding with an upgrade.

Comment 8 Red Hat Bugzilla 2007-08-21 05:29:21 UTC
User pnasrat@redhat.com's account has been closed

Comment 9 Gilboa Davara 2008-03-06 12:37:08 UTC
Does anyone know if this bug was fixed F7/8/rawhide?

- Gilboa

Comment 10 Bug Zapper 2008-04-04 04:35:48 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 11 Tony Nelson 2008-04-04 13:52:14 UTC
AIUI, the original bug that corrupted RPM databases is fixed, but there is still
no check of RPM database integrity in Anaconda, so no one can know for sure. 
Properly fixing the bug needs a change to Anaconda to check the RPM database
before using it.  I know that the checks are fairly weak, only checking each
table for integrity and not for referential integrity across the database, but
the checks have proven to be able to find many problems in the field.  Just
because they aren't perfect is a poor reason not to do useful checks before
starting a long process that depends on the RPM database.

Comment 12 John Poelstra 2008-04-04 19:54:55 UTC
Since the original bug is fixed, closing this bug.

Please open a new bug for the other issue.


Note You need to log in before you can comment on or make changes to this bug.