RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 592090 - RHEL6 Installer only detects 1 firmware raid device when there are 2
Summary: RHEL6 Installer only detects 1 firmware raid device when there are 2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dmraid
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Heinz Mauelshagen
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-13 20:01 UTC by Aaron Gee
Modified: 2010-10-13 12:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-13 12:10:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
/root/install.log.syslog (6.50 KB, text/plain)
2010-05-14 03:04 UTC, Aaron Gee 		no flags Details
/root/install.log (21.94 KB, text/plain)
2010-05-14 03:05 UTC, Aaron Gee 		no flags Details
results of dmraid -ay -t -vvv (2.17 KB, text/plain)
2010-05-15 19:31 UTC, Aaron Gee 		no flags Details
/tmp/syslog at point in install where drives are shown (44.68 KB, text/plain)
2010-05-15 19:32 UTC, Aaron Gee 		no flags Details
dmesg from anaconda prompt during install (39.99 KB, text/plain)
2010-05-19 15:50 UTC, Aaron Gee 		no flags Details
lspci from anaconda prompt (2.39 KB, text/plain)
2010-05-19 15:51 UTC, Aaron Gee 		no flags Details
dd dump of the beginning sda a corsair SSD (1.00 MB, application/octet-stream)
2010-05-19 15:52 UTC, Aaron Gee 		no flags Details
dd dump of the end of sda a corsair SSD (3.10 MB, application/octet-stream)
2010-05-19 15:53 UTC, Aaron Gee 		no flags Details
dd dump of the beginning of sdb a corsair SSD (1.00 MB, application/octet-stream)
2010-05-19 15:53 UTC, Aaron Gee 		no flags Details
dd dump of the end of sdb a corsair SSD (3.10 MB, application/octet-stream)
2010-05-19 15:53 UTC, Aaron Gee 		no flags Details
dd dump of the beginning sdc a Seagate Barracuda 7200.12 750G (1.00 MB, application/octet-stream)
2010-05-19 15:55 UTC, Aaron Gee 		no flags Details
dd dump of the end of sdc a Seagate Barracuda 7200.12 750G (2.87 MB, application/octet-stream)
2010-05-19 15:55 UTC, Aaron Gee 		no flags Details
dd dump of the beginning sdd a Seagate Barracuda 7200.12 750G (1.00 MB, application/octet-stream)
2010-05-19 15:56 UTC, Aaron Gee 		no flags Details
dd dump of the end of sdd a Seagate Barracuda 7200.12 750G (2.87 MB, application/octet-stream)
2010-05-19 15:56 UTC, Aaron Gee 		no flags Details
View All

Description Aaron Gee 2010-05-13 20:01:05 UTC 
Description of problem:

Installtion of RHEL6 does not detect all bios raid drives. System has 4 drives.  2 drives are convention SATA drives and 2 are Corsair SSD.  When using BIOS based RAID, the SSD drives are not detected as raid devices (Raid 0 or 1) while the raid device configured using the conventional hard drives are


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


How reproducible:Use 2 corsair SSD drives


Steps to Reproduce:
1.Install 2 corsair SSD drives
2.Use the bios to set the 2 drives in either RAID1 or RAID0
3.During install select advanced storage, click on bios raid tab.  The array is not present
  
Actual results:
No array detected

Expected results:
Array detected

Additional info:
Motherboard: Asus M4A89GTD Pro with latest firmware (Firmware dated 4/20/2010)
Chipset: AMD 890GX
Comment 2 RHEL Program Management 2010-05-13 21:40:36 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Chris Lumens 2010-05-14 02:32:16 UTC 
Please attach /tmp/syslog, /tmp/anaconda.log, and /tmp/storage.log to this bug report.  Thanks.
Comment 4 Aaron Gee 2010-05-14 03:04:27 UTC 
Created attachment 413937 [details]
/root/install.log.syslog
Comment 5 Aaron Gee 2010-05-14 03:05:39 UTC 
Created attachment 413938 [details]
/root/install.log

No /tmp log files were on my system (I went back UNDID the raid and then continued with the install).
Comment 6 Aaron Gee 2010-05-14 03:05:52 UTC 
No /tmp log files were on my system (I went back UNDID the raid and then continued with the install).
Comment 7 Aaron Gee 2010-05-14 03:06:52 UTC 
In my /tmp I have some sosreport-servers files.  Should I upload these as well?
Comment 8 Hans de Goede 2010-05-14 07:38:16 UTC 
Aaron,

Could you reproduce the original problem, and then when at the screen which only shows the 1 raid set, switch to tty2 (ctrl + alt + f2)

And do:
dmraid -ay -t -vvv > log

And attach the resulting log file here ? (you can use scp to get the file out of the installer environment). While at it please also collect /tmp/syslog and attach it here too.

Thanks,

Hans
Comment 9 Aaron Gee 2010-05-15 19:31:19 UTC 
Created attachment 414282 [details]
results of dmraid -ay -t -vvv

results of dmraid -ay -t -vvv as per request
Comment 10 Aaron Gee 2010-05-15 19:32:24 UTC 
Created attachment 414283 [details]
/tmp/syslog at point in install where drives are shown

/tmp/syslog as per request.
Comment 11 Hans de Goede 2010-05-16 07:50:57 UTC 
Ok, so dmraid only recognizes your 2 normal harddisks as part of a BIOS RAID set and even there I wonder if it is finding the correct metadata as it finds Promise RAID metadata, and I don't believe you have a promise controller in your system ?

My current hunch is that dmraid is not recognizing the dmraid metadata used by your BIOS RAID, and that the 2 regular disks used to be part of a promise RAID
set once upon a time and it is using that data now.

So I'm moving this over the dmraid and keeping myself in the CC.

Could you collect the following data to help out Heinz (the dmraid maintainer):
1) Tell us what sort of Firmware RAID you are using (nvidia / intel / jmicron
   or ...)
2) For each disk (after configuring it as part of a RAID set in the RAID BIOS)
   do:
   dd if=/dev/sdX of=sdX-begin.dump bs=1M count=1
   dd if=/dev/sdX of=sdx-end.dump bs=1M count=4 skip=xxxx

   Where by skip needs to be such a value that dd runs of the end of the
   disk and thus the resulting dump is smaller then 4MB (and larger then 1MB)

And then attach the dumps here.
Comment 12 Aaron Gee 2010-05-16 11:53:37 UTC 
3 items

1. None of the drives had ever been used in any system, the are literally brand new just out of the packaging.

2. The RAID controller is part of the AMD SB850 southbridge, while it "looks and feels" like promise, I believe it is AMD specific and supports RAID 0,1,5,10

3. Is it possible to manually create MD devices and install on them, and or manually handle the partitioning schema?  I did not find such an option when I did the installation which is frustrating in my situation where I was trying to test a mixed SSD/Conventional disk environment for virtualization.  The default disk arrangement chosen by the installer worked - but I'd like some more flexibility.

I will get the dumps later and attach.
Comment 13 Hans de Goede 2010-05-16 12:46:59 UTC 
(In reply to comment #12)
> 3 items
> 
> 1. None of the drives had ever been used in any system, the are literally brand
> new just out of the packaging.
> 

Thx, that is useful info.

> 2. The RAID controller is part of the AMD SB850 southbridge, while it "looks
> and feels" like promise, I believe it is AMD specific and supports RAID
> 0,1,5,10
> 

And yet more useful info :)

> 3. Is it possible to manually create MD devices and install on them, and or
> manually handle the partitioning schema?  I did not find such an option when I
> did the installation which is frustrating in my situation where I was trying to
> test a mixed SSD/Conventional disk environment for virtualization.  The default
> disk arrangement chosen by the installer worked - but I'd like some more
> flexibility.
> 

Yes it is possible to use a custom disklayout, when asked if you want
to remove pre-existing linux / entirely clear disks or use free space you can also choose custom partitioning, from there you can create mdraid partitions and then on top of those partitions mdraid sets.
Comment 14 Aaron Gee 2010-05-19 15:50:57 UTC 
Created attachment 415167 [details]
dmesg from anaconda prompt during install
Comment 15 Aaron Gee 2010-05-19 15:51:24 UTC 
Created attachment 415169 [details]
lspci from anaconda prompt
Comment 16 Aaron Gee 2010-05-19 15:52:25 UTC 
Created attachment 415171 [details]
dd dump of the beginning sda a corsair SSD
Comment 17 Aaron Gee 2010-05-19 15:53:03 UTC 
Created attachment 415172 [details]
dd dump of the end of sda a corsair SSD
Comment 18 Aaron Gee 2010-05-19 15:53:34 UTC 
Created attachment 415173 [details]
dd dump of the beginning of sdb a corsair SSD
Comment 19 Aaron Gee 2010-05-19 15:53:59 UTC 
Created attachment 415174 [details]
dd dump of the end of sdb a corsair SSD
Comment 20 Aaron Gee 2010-05-19 15:55:28 UTC 
Created attachment 415177 [details]
dd dump of the beginning sdc a Seagate Barracuda 7200.12 750G
Comment 21 Aaron Gee 2010-05-19 15:55:53 UTC 
Created attachment 415178 [details]
dd dump of the end of sdc a Seagate Barracuda 7200.12 750G
Comment 22 Aaron Gee 2010-05-19 15:56:20 UTC 
Created attachment 415179 [details]
dd dump of the beginning sdd a Seagate Barracuda 7200.12 750G
Comment 23 Aaron Gee 2010-05-19 15:56:51 UTC 
Created attachment 415180 [details]
dd dump of the end of sdd a Seagate Barracuda 7200.12 750G
Comment 24 RHEL Program Management 2010-07-15 14:03:53 UTC 
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 25 Heinz Mauelshagen 2010-10-13 12:10:57 UTC 
(In reply to comment #17)
> Created attachment 415172 [details]
> dd dump of the end of sda a corsair SSD

This looks like Promise metadata in an unsupported offset on the disk, hence you can't use them as BIOS RAID, just mdraid.
Note You need to log in before you can comment on or make changes to this bug.