Bug 18136 - initrd.img fails on upgrade request
initrd.img fails on upgrade request
Status: CLOSED DUPLICATE of bug 18019
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Michael Fulbright
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-02 16:32 EDT by James L. Stadelmann
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-08 12:55:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Signature & md5sum for Key: openssl (94 bytes, text/plain)
2000-10-04 21:11 EDT, James L. Stadelmann
no flags Details

  None (edit)
Description James L. Stadelmann 2000-10-02 16:32:41 EDT
Attempting to upgrade to RH 7.0 from working RH 6.2 (2.2.16-3 kernel) from
floppy using HardDriveINstallMethod fails with Anaconda Error.  While
similar failures have been previously reported, this differs in that it is
an attempt to upgrade from an existing drive partition so the dump file
from the anaconda script differs.  The error occurs whether using expert or
text mode when choosing upgrade option.

It is being reported as a high priority, high severity item simply because
it makes installation and any use of the Release impossible.

System: i386 (250MHz PI MMX on Tyan Turbo MB - not overclocked) RH6.2
installed with all security & bug upgrades, 2.2.16-3 kernel)

ANACDUMP.TXT:

Traceback (innermost last):
  File "/usr/bin/anaconda.real", line 438, in ?
    intf.run(todo, test = test)
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/text.py", line 1028, in
run
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/text.py", line 279, in
__call__
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 941, in
upgradeFindPackages
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 539, in
getCompsList
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/harddrive.py", line 43,
in readComps
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/comps.py", line 459, in
__init__
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/comps.py", line 428, in
readCompsFile
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/comps.py", line 101, in
__getitem__
KeyError: openssl

Local variables in innermost frame:
self: <comps.HeaderList instance at 8232458>
item: openssl

ToDo object:
(itodo
ToDo
p1
(dp2
S'method'
p3
(iharddrive
HardDriveInstallMethod
p4
(dp5
S'fstype'
p6
S'ext2'
p7
sS'isMounted'
p8
I1
sS'fnames'
p9
(dp10

<failed>
Comment 1 Michael Fulbright 2000-10-03 16:22:23 EDT
Probably forgot to specify 'binary' mode when ftpping the files.

Due to corrupted download.

*** This bug has been marked as a duplicate of 18031 ***
Comment 2 James L. Stadelmann 2000-10-04 15:06:28 EDT
This Bug Report (18136) differs both in circumstances and environment from
18031.  

18031 refers to the inability to access a single file on a burned CD.
18136 refers to the inability to begin a Update from a HD partition.
The diagnostics produced from Anaconda differ as well.
There were a number of bug reports, many differing in nature, which indicate
that different parts of the script were returning errors from those in 18031.

That the developer apparently failed to contact any of the complaintants for
clarification or additional information to make this determination may be an
error.  This complaint relates to an Upgrade using an ext2 parition, not a CD or
a DOS parition and thus the incident differs materially from 108031.

With regard to this report, the developer presumes that the binaries were
downloaded in ascii mode.  Of course, the binary image which was downloaded at
the same time and used to make the boot floppy to initiate the install procedure
was obviously correctly downloaded.

Additionally the downloaded binary rpm images were verified using rpm-3.0.5-9.6x
prior to the install attempt.

I don't believe such a cavalier attitude displayed to those conscientious users
who all took considerable effort to correctly report their problems is conducive
to successfully rolling out a new product like RH 7.0 which can be expected to
initially have a considerable number of bugs.

I strongly recommed in the future, that if the assignee suspects such problems,
he/she at least attempts to e-mail the poster to verify such was the case before
closing out the complaint.  

It is for these two reasons, I am reopening this report:  The incident is
sufficiently different from 18031 to be handled separately;  the presumption
regarding the asci download of binary rpms is incorrect and the diagnostics
generated by Anaconda do nothing to assist in diagnosing the underlying cause of
the failure.

Since it completely prevents, in this case, any upgrade to RH 7.0, I will retain
the high-priority, high-severity tags.  If the developer can identify to me
which files he suspects are corrupted, I will check them, re-acquire them if
necessary, and reattempt the upgrade - and I will close the incident report if
this resolves the on-going problem.

James L. Stadelmann
ARE Enterprises
Comment 3 James L. Stadelmann 2000-10-04 21:11:26 EDT
Created attachment 3778 [details]
Signature & md5sum for Key: openssl
Comment 4 Matt Wilson 2001-01-04 00:52:12 EST
moving to anaconda comp.
Comment 5 Matt Wilson 2001-01-04 03:49:49 EST
(this fell off our scope when you changed it from anaconda to ImageMagick)
Comment 6 Michael Fulbright 2001-01-09 16:17:36 EST
My mistake, this is a dupe of bug 18019.

We hav done numerous hard drive installs and upgrades and not been able to
reproduce the reported issue.

If you would like to give step by step instructions of the steps you took to
cause this problem we will try to reproduce your setup.
Comment 7 Michael Fulbright 2001-02-08 12:55:24 EST

*** This bug has been marked as a duplicate of 18019 ***

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