Bug 68198 - Mylex DAC960: root mount failed at boot
Summary: Mylex DAC960: root mount failed at boot
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-08 00:41 UTC by Bojan Smojver
Modified: 2007-04-18 16:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-24 03:12:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bojan Smojver 2002-07-08 00:41:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606

Description of problem:
After successful installtion of RH 7.3 on the box and during the first boot, the
root filesystem cannot be mounted (error 6).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install RedHat 7.3 on ALR Revolution Quad 6 with DAC960PDU
2. Reboot the system using any kernel (SMP or UP)

Actual Results:  The root filesystem cannot be mounted (/dev/rd/c0d0p2). The
mount error reported is 6. Call to pivot_root fails. Finally boot process
reports that init cannot be found (probably because the root filesystem could
not be mounted) and then the kernel panics.

Expected Results:  Should boot? ;-)

Additional info:

Booting in rescue mode mounts all filesystems just fine.

Tried DAC960 in both 2GB and 8GB mode. In 8GB mode fdisk reports discrepancies
in disk geometry, but the OS still gets installed OK. I'm suspecting that the
problems could be in this area since the README.DAC960 file talks about 8GB
geometry as recommended for large disk arrays (if 4 GB qualifies as large these

Built my own statically linked kernel from vanilla 2.4.19-rc1, copied it over
via NFS (while in rescue mode), fixed /boot/grub/grub.conf, reboot, but with the
same result.

For the record, the system has 6 disks: 2 x 4B + 2 x 18 GB. The first two are
configured RAID 1, the last 4 RAID 10 (or RAID 6 in Mylex terminology).
Partitions are:

/dev/rd/c0d0p1 -> /boot (50MB)
/dev/rd/c0d0p2 -> /     (1.7GB)
/dev/rd/c0d0p3 -> /var  (1.7GB)
/dev/rd/c0d0p4 -> swap
/dev/rd/c0d1p1 -> /home (34GB)

There is another SCSI controller in the system, Symbios Logic 810, which runs
the tape drives and CD-ROM, but removing it made no difference.

The system works fine with NetRAID 3Si controller (a.k.a. AMI MegaRAID) pulled
from another system.

This system is a really old 4-way Pentium Pro machine. The above configuration
(with DAC960PDU) ran SCO OpenServer 5.0.5 just fine.

Comment 1 Joshua Baker-LePain 2002-07-17 19:16:09 UTC
This has been fixed in 2.4.18-5.  The kernel doesn't know the hex address
of the /dev/rd devices.  Either use 2.4.18-5 or specify root=300x (where x
is the number of your root partition) in grub.conf.

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