Bug 103153 - Installer considers all devices as DASD and offers no steering
Installer considers all devices as DASD and offers no steering
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
s390 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-27 05:00 EDT by Rob van der Heij
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-11 11:25:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
console log of the install (46.87 KB, text/plain)
2003-08-27 10:00 EDT, Rob van der Heij
no flags Details

  None (edit)
Description Rob van der Heij 2003-08-27 05:00:02 EDT
Description of problem:
The installer attempts to add all devices to the Linux dasd driver and even
decides to format the disk without interaction with the user. There does not
seem to be a way to restrict the range of dasd devices the installer picks
up. 

Version-Release number of selected component (if applicable):
initrd dated Jul 22 00:43
netstg2.img  Jul 22 00:44

How reproducible:
Installing in a virtual machine the console is filled with lots of msgs like
dasd: <devno 000e> Add lowmem page :...
dasd: device range 019b-019b: device 019b already in a range 

Additional info:
I believe earlier versions used the DASD= option in the parameter
file that is used for the first part of the configuration.
Comment 1 Karsten Hopp 2003-08-27 09:43:44 EDT
I've tested this with our latest images on s390 and s390x with a DASD=XXX parameter in 
the .parm file. Only the defined dasds were probed and added to /proc/dasd/devices. 
Did you test this in hercules ? We could reproduce this in hercules, but not on real hardware. 
Or did you leave out the DASD= parameter ? We accidently left it out in our documentation but 
added it in the meantime. 
 
Can you please elaborate on 'decides to format the disk without interaction with the user' ? 
Which DASD has been reformatted ? Has it been a CMS disk or maybe a LDL formatted disk ? 
Comment 2 Rob van der Heij 2003-08-27 10:00:37 EDT
Created attachment 93973 [details]
console log of the install

The log shows the DASD=200-207 and further down you see the installer tamper
with devices outside that range (not even disks).
Comment 3 Rob van der Heij 2003-08-27 10:05:18 EDT
The log file shows the installer tampering with devices outside that list. Also,
a nother disk in the specified range but not formatted was not picked up.

Re: unsolicited formatting
This was a recycled virtual machine, so the disk was probably CDL format and
most likely had a ReiserFS filesystem on it. If really helpful I can make sure
to try with that combination next time I run the install. 
Comment 4 Karsten Hopp 2003-08-27 10:47:08 EDT
easy fix: reorder your .parm file so that DASD= isn't the first parameter in the .parm file. 
I've already committed the real fix to CVS. 
Comment 5 Bill Nottingham 2004-10-11 11:25:33 EDT
Closing MODIFIED bugs as fixed. Please reopen if the problem perists.

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