Bug 171738 - Install Crashes Loading RPMs from Bad Media
Install Crashes Loading RPMs from Bad Media
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-25 16:04 EDT by David
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-07 21:23:59 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)

  None (edit)
Description David 2005-10-25 16:04:39 EDT
Description of problem:
Trying to install FC4 on a dualboot machine with Win2K and earlier (SuSE8) 
linux distro. 2 year-old AMD Athlon 256M RAM, 2 HDD (60G & 40G). Working with 
the 4-CD set. Verified first CD, and assumed that later CDs, being RPM 
repositories would be OK. Disk 3 was bad, and the install hung. 

I tried re-creating the CD on a second machine, without downloading a new ISO 
but just the RPMs that were corrupt on the first copy. This did not work 
because the .discinfo file was not copied. Subsequent efforts to copy this file 
(in both Windows AND Linux) failed. I had to cancel the install, with the 
result that the machine was dead in the water; the previous GRUB install was 
trashed. Several hours later, I was able to select options to install that 
miraculously skipped disc 3, and I got up and running.

Observation 1: if FC4 is going to trash a computer because of corrupt media, 
then the media check shouldn't be optional. (I do note that there are issues 
with the media check)

Observation 2: if FC4 wants to check for disc IDs, why not make them copyable?

Observation 3: GRUB installation and configuration should be early in the 
system install process so that if subsequent packages fail to install, the 
system isn't completely unbootable.

Observation 4: discs 2-4 are RPM repositories. It is unclear to me why FC4 
needs the .discinfo validation in the first place. If I can provide a CD that 
has the right RPMs on it, why does FC4 need a particular key to unlock it? BTW, 
this requirement holds even after FC4 is installed, and I want to add 
applications using the included GUI.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jeremy Katz 2005-11-07 21:23:59 EST
The .discinfo is required so that we know what CD you've put in -- otherwise,
there's no way to tell.  This is why mediacheck is strongly recommended --
people complain about it even as-is.
Comment 2 David 2005-11-08 21:43:55 EST
Jeremy--

Thanks for the reply, but you make no mention about the observations I made. 
Honestly, I don't see why those observations are invalidated by the need to 
know which disk is in the machine.

I especially think that if the FC install is going to turn a computer into a 
doorstop (there's a joke in there), there's a responsibility on the installer 
either to be more rigid (i.e. requiring media checks) or more flexible (i.e., 
allowing users to copy discinfo or not requiring discinfo at all).

Moreover, it seems to me that if people are "complaining about it", that maybe 
there's a problem with the assumptions of the installer software. I am a firm 
believer of the saying "the customer is right"--and this sounds like a case of 
the software not taking into account the realities of human nature.

Sincerely,
David

(In reply to comment #1)
> The .discinfo is required so that we know what CD you've put in -- otherwise,
> there's no way to tell.  This is why mediacheck is strongly recommended --
> people complain about it even as-is.


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