This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 40760 - Installer failed to install Lilo on mbr on system with scsi zip drive
Installer failed to install Lilo on mbr on system with scsi zip drive
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-15 14:16 EDT by Will Henry
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-10 00:31:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Will Henry 2001-05-15 14:16:33 EDT
Description of problem:
Disk installer sees scsi zip drive as sda and scsi hard drives as sdb and 
sdc.  Result is that it won't install Lilo on my hard drive so I must boot 
from a floppy.

How reproducible:
Always

Steps to Reproduce:
1.Graphical install
2.Partition disk with Disk Druid or Fdisk (will get message that sda is 
invalid block device or something like that)
3.Hard drives will be partitioned but Lilo installation to mbr fails (will 
get message that sda is invalid media)
4.System hangs on reboot because there is no valid mbr so must use floppy 
to boot.
	

Actual Results:  Linux successfully installed but will only boot from 
floppy.

Expected Results:  Successful installation which boots from first hard 
drive.

Additional info:

My system is a SuperMicro P6DBE dual PII400 with 384MB RAM and an Advansys 
3940U2W scsi controller with a Sony CD-RW and an IOmega zip drive on the 
UW channel and two 4GB IBM drives on the U2 channel.

The problem is the installer insists on seeing the zip drive as the first 
hard drive and thus insists the mbr be place there.  I got a successful 
install by removing the zip drive prior to installing Linux and re-
attaching it following the install.  It would be nice to have the ability 
to choose which device will have the mbr from the installer.
Comment 1 Brent Fox 2001-05-17 14:25:26 EDT
That's strange, because I have an internal zip in one of my test machines and 
have not seen this problem.  However, mine is on the IDE bus and not the SCSI
bus, so that probably makes the difference.  After you've got the machine
installed and reattached the device, what device does the kernel see the zip
drive as?  sda, sdb, or sdc?
Comment 2 Will Henry 2001-05-22 15:56:55 EDT
It sees the zip as sda after I successfully install linux and reattach the 
drive.  Since there is no boot disk in the zip drive the system skips it and 
boots off of the hard drive.

One additional bit of information for what it's worth, my system uses software 
raid for all partitions except the swap and /boot.

I suspect the root of the problem is that the system scans the UW SCSI bus 
first, where the zip is, and then scans the U2 SCSI bus, where the hard drives 
are.  I don't know of any way to change this.  However, it seems to me that 
linux should recognize that the mbr doesn't belong on the zip drive.  It 
doesn't try to put it on the floppy or CDRW so why does it try to put it on the 
zip?  It appears linux thinks the zip is a hard drive.
Comment 3 Brent Fox 2001-07-06 01:26:21 EDT
We don't have an internal SCSI zip drive.  We have an external SCSI one, but I
was not able to reproduce this behavior.  It could be because there are two scsi
busses in the computer.  We don't really have a way of figuring out which SCSI
bus should be the primary controller.  I think that might be the root of the
problem.
Comment 4 Brent Fox 2001-07-10 00:31:08 EDT
I've talked to the other developers and here's the situation.  The kernel scans
the PCI bus in ascending order.  The first controller it finds is considered the
primary controller, and that's what it installs to.  You might try changing the
bus order of the controllers in the bios, or changing their order inside the
machine.  Other than that, we don't really have a way of fixing the problem.

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