Bug 18136
| Summary: | initrd.img fails on upgrade request | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | James L. Stadelmann <are> | ||||
| Component: | anaconda | Assignee: | Michael Fulbright <msf> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 | CC: | are | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2001-02-08 17:55:29 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Probably forgot to specify 'binary' mode when ftpping the files. Due to corrupted download. *** This bug has been marked as a duplicate of 18031 *** 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 Created attachment 3778 [details]
Signature & md5sum for Key: openssl
moving to anaconda comp. (this fell off our scope when you changed it from anaconda to ImageMagick) 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. |
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>