Bug 134669

Summary:	Installation to machine with attached SAN storage problematic
Product:	Red Hat Enterprise Linux 4	Reporter:	Joshua Jensen <joshua>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED WONTFIX	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	nobody+pnasrat
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-10-05 16:26:11 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:

Description Joshua Jensen 2004-10-05 15:16:22 UTC

Description of problem:

Problems when installing RHEL4 Beta to a machine that is seeing
multiple LUNS.  Novice system admin have been known to install the /
partition to a SAN partition, overwriting very important data.

However, even if a partition from the hard drive is installed to,
grub.conf will be written incorrectly if the SAN storage is /dev/sda
(aka, comes before the hard drive partitions scsi-wise).  grub will
reference sda thinking it is the "first scsi drive", and the machine
won't boot after installation.

Expected results:

Given these two problems, I'd like to see all HBA drivers removed from
the bootdisk/cdrom/pxe images.  I don't believe that installing to a
SAN is supported anyway.

Comment 1 Jeremy Katz 2004-10-05 16:26:11 UTC

Unfortunately, there isn't a clear delineation between what drivers
are used for SANs and what are used for other things.  People will use
adapters which require the qlogic driver for internal disks (see a lot
of IA64 boxes)

With RHEL4, there is an attempt to make this somewhat better via the
use of putting a small fingerprint in part of the partition table
where nothing else is required to be.  This area is then read in by
the kernel at boot time when real mode is still present so that you
can later map bios disk 0x80 to an actual disk and then I order disks
using that instead of sda, sdb, ...

If only hardware didn't suck, I'd do more :(