Bug 30488 - upgrade fails while 'finding packages to update'
upgrade fails while 'finding packages to update'
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Brent Fox
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-03 16:16 EST by Dana P. Cook
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-28 00:00:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dana P. Cook 2001-03-03 16:16:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2 i686)


System crashes while trying to do an upgrade from RedHat7.0
to fisher beta. I get to the point where I choose upgrade, then 
I go to the screen where it allows me to selct customize. No matter wether
I choose customize or not when I hit next it pops up a 
window saying "finding packages to update" ( wording may not be exact)
The hard drive then churns for about 5-10 minutes and finaly the system
returns to console mode and shuts down ( panic? )

The following error line is reported :
python:header.c:496:headerLoad:Assertion `rdlen == dl` failed

Reproducible: Always
Steps to Reproduce:
1. Boot from cd ( IDE )
2. Choose upgrade ( From Redhat 7.0 system )
3.
	

Actual Results:  The hard drive then churns for about 5-10 minutes and
finaly the system returns to console mode and shuts down ( panic? )

The following error line is reported :
python:header.c:496:headerLoad:Assertion `rdlen == dl` failed

Expected Results:  upgrade process should have started upgrading packages

My system is a sager laptop with IDE disks, 256Mem, 1.5 gig available
disk. It has run every version of redhat since 5.2 with no issues.
It is a PII400

I was running the 2.4.2 kernel on the system being upgraded
( not that it should matter ). The upgrade was being done from a local
bootable cd drive.

If I can provide further info ( package db? ), please contact me.
danacook@metrocast.net
Comment 1 Michael Fulbright 2001-03-03 20:53:35 EST
Please try wolverine, our more recent beta.
Comment 2 Dana P. Cook 2001-03-05 13:06:48 EST
retried with wolverine release and saw same results. The line number
of the error moved to Line 551.
Comment 3 Michael Fulbright 2001-03-05 15:27:41 EST
Please look at VC3 and VC4 (cntl-alt-f3 and -f4) and see if you are getting read
errors during the long pause.
Comment 4 Dana P. Cook 2001-03-05 15:56:57 EST
tried to view ctrl-alt-f3 and ctrl-alt-f4 durring pause and after
the system panic. At no time did I see anything being appended to the
system startup info that is there when the process begins. I browsed
through the entries in these windows and did not see anything that 
looked abnormal.
Comment 5 Brent Fox 2001-03-13 12:27:09 EST
Are you able to type on VC2?  If so, what does 'cat /proc/meminfo' say?  How
much swap space does your machine have?  The 2.4 kernel needs more swap than the
2.2.x kernels did, so your system may be running out of swap.
Comment 6 Dana P. Cook 2001-03-13 13:50:14 EST
I was able to get memory stats in vc2. The machine has 256M memory and
256M swap partition. When I press "next" to start the upgrade I have about
140M of mem Free and swap has not been used. I dumped /proc/meminfo every 
10 seconds or so and watched the FreeMemory drop at a rate of a few meg/minute.
My last dump before it dies showed 118M free and swap still not touched...

Here is what the lasts memstats screen said :
MemTotal : 255768
MemFree  : 118312
MemShared : 0
Buffers : 4932
Cached : 73944
Active : 43584
Inact_drty : 35292
Inact_clean : 0
Inact_target : 160
SwapTotal : 265032
SwapAvailable : 265032
Comment 7 Brent Fox 2001-03-14 12:16:59 EST
Trond, is this a duplicate of your bug?
Comment 8 Trond Eivind Glomsrxd 2001-03-14 12:49:10 EST
No, no system panic or other bug messages on my problem .
Comment 9 Brent Fox 2001-03-15 16:44:09 EST
If you just boot the machine without the installer, does the installed system
run correctly after the failed upgrades?  We have seen some problems with
upgrading in house in that the machines will sometimes hang during the upgrade,
but it's usually at the very end of the install...and we haven't seen a system
return to console mode and shut down...the GUI just gets frozen and doesn't do
anything.
Comment 10 Dana P. Cook 2001-03-15 17:56:36 EST
I'm sorry, but I don't really know what you are asking here. What do
you mean "without the installer" and "installed system"? When I have 
attempted an install and it fails, the computer I am attempting to upgrade
has not been touched. It continues to function as it did before attempting
to upgrade it. I don't beleive that there have been any changes made to my
existing system because the upgrade did not get far enough to actually 
upgrade any packages. If this doesn't cover what you are asking, please
be more specific and I'll try again...
Comment 11 Brent Fox 2001-03-19 11:32:28 EST
Your answer covers what I was asking.  I wanted to know if the system was
working properly with 7.0, just to make sure we are starting from a 'known good'
state and it appears that we are.
When the system crashes, exactly what appears on the screen?  Is it a python
traceback?  In your original report, you said that the message:
'python:header.c:496:headerLoad:Assertion `rdlen == dl` failed'
appears.  I'm a little confused because I can't find any file named 'header.c'
in the installer.
Comment 12 Dana P. Cook 2001-03-19 14:35:01 EST
When the crash happens It looks like I get returned to a VC. It prints the 
python error and then a short series of kernel shutdown messages.
The python error I listed above is verbatum of what is on the screen.
Please note however that on a followup ( testing with wolverine instead
of fisher ) the error line is 551.
Comment 13 Brent Fox 2001-03-23 15:17:17 EST
Can you attach a copy of your package db?  That would be helpful.
Comment 14 Brent Fox 2001-03-23 15:18:33 EST
Adding jbj to the list...the problem could stem from a problem with the rpm
package db.
Comment 15 Dana P. Cook 2001-03-23 17:49:42 EST
I'd be happy to. What filename/path would that be?
Comment 16 Jeff Johnson 2001-03-24 09:30:42 EST
Just do
	cd /var/lib
	tar czvf /tmp/rpmdb.tar.gz rpm
and mail me <jbj@redhat.com> rpmdb.tar.gz. Thanks.
Comment 17 Dana P. Cook 2001-03-26 15:12:29 EST
I just upgraded my redhat7.0 system to use the following
updates :

rpm-4.0.2-7x.i386.rpm        rpm-devel-4.0.2-7x.i386.rpm
rpm-build-4.0.2-7x.i386.rpm  rpm-python-4.0.2-7x.i386.rpm

I now get the same error message I reported above when I
do a "rpm -qa" command.  Here is the error :

rpmq: header.c:511: headerLoad: Assertion `rdlen == dl' failed.

Thought this might help you diagnose since it seems related...

Comment 18 Brent Fox 2001-03-26 16:07:13 EST
If this is appearing outside the context of the installer, I'm inclined to think
the problem is somewhere in rpm.  Changing component to rpm.  If I am wrong
here, please reassign it back to anaconda.
Comment 19 Jeff Johnson 2001-03-26 16:49:32 EST
Your Packages hash is damaged, verify by doing (you will need db3-utils
installed):
    bash$ cd /var/lib/rpm
    bash$ db_verify Packages 
    db_verify: Overflow page 3085 has bogus prev_pgno value
    db_verify: Overflow item incomplete on page 3090
    db_verify: DB->verify: Packages: DB_VERIFY_BAD: Database verification failed

That can be "fixed" by doing
    bash$ cd /var/lib/rpm
    bash$ mv Packages Packages-BUGGY
    bash$ db_dump Packages-BUGGY | db_load Packages

However the problem persists, verify using "rpm -qa".
But "db_verify Packages" is happy.

So, the assumption is that this is (known) file system corruption running 
kernel-2.4.2 on IDE.

Comment 20 Dana P. Cook 2001-03-26 18:41:12 EST
The last set of operations you described behaves
exactly as you predicted.
Comment 21 Brent Fox 2001-03-28 00:00:01 EST
Closing the bug since the rpm database was corrupt to begin with.

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