Bug 61571

Summary:	7.2 will not install on huge 3ware array
Product:	[Retired] Red Hat Linux	Reporter:	Jason Tibbitts <j>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-05-19 22:11:56 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 Jason Tibbitts 2002-03-21 17:43:55 UTC

The installer will not let me partition a 1.1TB array (8x160GB disks, RAID5)
behind a 3w-7850 controller.

I have tried with both errata images; they solve other problems and both allow
me to get further into the installation.  Now I get no indication of any errors
in the kernel log.  Instead I get the following in a dialog box:

No such file or directory during read on /tmp/sda

The kernel logs on VT4 look normal except for this:

<4>SCSI device sda: -2053770239 512-byte sectors (47981MB)

Obviously it's overflowing.  I'm used to this, because it also happens on a
700MB array I have running Red Hat 7.1, but it didn't cause any problems with
the installation there.  I no longer have 7.1 around to install on the new machine.

Choosing "ignore" from the dialog box causes the above message to again appear
in the kernel log.  Then the dialog box reappears; after several tries, I get
the "no devices found for installation" box.

I have verified (from the shell on VT2) that /tmp/sda exists as a block device
with major 8 and minor 0 as I'd expect.

Comment 1 Jason Tibbitts 2002-03-21 17:50:03 UTC

Some further information:

On VT2, running fdisk /tmp/sda results in:

Unable to read /tmp/sda

I verified again that /tmp/sda does indeed exist, and to be doubly sure I did
"mknod /tmp/blah b 8 0" and received the same error message when trying to fdisk
that.

Comment 2 Jeremy Katz 2002-03-21 21:46:12 UTC

What happens if you create /tmp/sda and try to run parted on it ?

Comment 3 Jason Tibbitts 2002-03-21 22:03:14 UTC

I didn't realize that parted was available in the initial install image.

It runs and gives a prompt.  There is a note about the geometry being
139508/255/63 and cylinder 1024 ending at 8032.499M.

However, it doesn't want to do much of anything.  If, for instance, I do
"mklabel msdos" I get:

read failed: No such device
read failed: No such device
Error: No such file or directory during read on /tmp/sda
Retry Ignore Cancel?

I hope this helps.

Comment 4 Jeremy Katz 2002-03-22 00:15:12 UTC

Arjan -- do you know of anything specific to the boot kernel that might be
causing problems here?

Comment 5 Jason Tibbitts 2002-03-22 19:30:58 UTC

Some more information for you:

I brought up a RAID5 array with only three 160GB disks, to try and determine
whether the problem relates to the size of the array.  The installation works
fine on the resulting 320GB /dev/sda.

3ware has a driver out that's even newer than what is in current kernels
(1.02.00.019, I think).  Unfortunately I have no idea how to make the new driver
available to the installer.

Comment 6 Jeremy Katz 2002-04-04 23:16:20 UTC

Sounds like the kernel driver is having problems with something that large

Comment 7 Arjan van de Ven 2002-04-05 09:27:12 UTC

Several linux drivers (and it seems the 3ware too) have a 1 Tb limit ;(

Comment 8 Jason Tibbitts 2002-04-05 18:38:29 UTC

The limit seems to be in the kernel on the boot floppies.  I know that newer
kernels have no trouble with an array this large.

In any case, Skipjack-beta1 installs fine on this machine, so you can resolve
the issue.  But this is supposed to be a production machine, and running the
beta makes me unconfortable.  We'll see how it survives stress testing.

Comment 9 Jason Tibbitts 2002-04-22 15:06:26 UTC

I suggest that this be resolved, since this particular problem is fixed in the
betas (and I'm sure you want to keep the unresolved bug count down).

Is that "resolved current" or "resolved rawhide"?