Bug 18136 - initrd.img fails on upgrade request
Summary: initrd.img fails on upgrade request
Status: CLOSED DUPLICATE of bug 18019
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-02 20:32 UTC by James L. Stadelmann
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-08 17:55:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-05 01:11 UTC, James L. Stadelmann
no flags Details

Description James L. Stadelmann 2000-10-02 20:32:41 UTC
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)


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
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/text.py", line 279, in
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 941, in
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 539, in
  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
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/comps.py", line 428, in
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/comps.py", line 101, in
KeyError: openssl

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

ToDo object:


Comment 1 Michael Fulbright 2000-10-03 20:22:23 UTC
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 19:06:28 UTC
This Bug Report (18136) differs both in circumstances and environment from

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-05 01:11:26 UTC
Created attachment 3778 [details]
Signature & md5sum for Key: openssl

Comment 4 Matt Wilson 2001-01-04 05:52:12 UTC
moving to anaconda comp.

Comment 5 Matt Wilson 2001-01-04 08:49:49 UTC
(this fell off our scope when you changed it from anaconda to ImageMagick)

Comment 6 Michael Fulbright 2001-01-09 21:17:36 UTC
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 17:55:24 UTC

*** 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.