Bug 134669 - Installation to machine with attached SAN storage problematic
Installation to machine with attached SAN storage problematic
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-05 11:16 EDT by Joshua Jensen
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-05 12:26:11 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)

  None (edit)
Description Joshua Jensen 2004-10-05 11:16:22 EDT
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 12:26:11 EDT
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 :(

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