Bug 504429 - Dmraid results for nforce4 fakeraid
Dmraid results for nforce4 fakeraid
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-06 18:27 EDT by Rehan Khan
Modified: 2009-06-07 05:21 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-07 03:25:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (4.03 KB, application/octet-stream)
2009-06-06 18:28 EDT, Rehan Khan
no flags Details
Storage.log (4.08 KB, application/octet-stream)
2009-06-06 18:28 EDT, Rehan Khan
no flags Details
Dmraid output (3.15 KB, application/octet-stream)
2009-06-06 18:29 EDT, Rehan Khan
no flags Details

  None (edit)
Description Rehan Khan 2009-06-06 18:27:15 EDT
Description of problem:
A further test on a Nvidia Nforce4 chipset Raid of booting the may2009 boot.iso which fails to detect a raid0 and raid5 configuration on the onboard Nvidia Mediashield (fake)Raid. This test appears to detect the raid but anaconda produces a traceback. Additionally, when running the dmraid command piped to a file the console outputs a couple of messages saying something like 'raid45 not in kernel' 

The setup is an Asus A8N32SLI Deluxe motherboard with an Nforce4 chipset. The motherboard has 4 nvidia sata ports configured as Raid ports with three 1TB Samsung drives configured as a Raid 5 and one 500Gb Smasung drive configured as a 1 disk Raid0. The motherboard also has a SIL3112 chip supporting 2 sata ports with one 500gb Samsung drive attached. The only drive with un-partitioned space was the drive on the sil3112. All other drives had ntfs partitions.

Version-Release number of selected component (if applicable):
MAY2009 boot.iso

How reproducible:
Seems to be every boot produces the same result (attempted three times)

Actual results:
See attached dmraid -a y -vvv output, anaconda.log and storage.log. The anaconda.log has the backtrace. Anaconda locked up when I tried to post the backtrace from within the install.
Comment 1 Rehan Khan 2009-06-06 18:28:00 EDT
Created attachment 346765 [details]
Comment 2 Rehan Khan 2009-06-06 18:28:43 EDT
Created attachment 346766 [details]
Comment 3 Rehan Khan 2009-06-06 18:29:33 EDT
Created attachment 346767 [details]
Dmraid output
Comment 4 Rehan Khan 2009-06-06 18:35:16 EDT
I should mention this motherboard has a newer Nvidia mediashield firmware than the last one released for this motherboard by Nvidia. It was a community bios build to update the Mediashield and SIL 3112 firmware to allow the use of more up to date drivers. The firmware was taken (I guess) from firmware released with later Nvidia motherboards. It works fine with Windows XP and Windows Server 2003.
Comment 5 Hans de Goede 2009-06-07 03:25:34 EDT

Indeed fake (motherboard raid) 5 is not yet supported in the upstream kernel,
and thus not yet supported in Fedora. This is causing the crash you are seeing
(sad but true).

Given that we're too close to F-11 to fix this, and we expect to have dmraid45 in the kernel which will be in F-12, I'm going to close this as wontfix (wontfix for F-11 that is, for F-12 the problem should go away once we have kernel support).
Comment 6 Rehan Khan 2009-06-07 05:21:52 EDT
Thanks for the info. It's a shame that anaconda(?) crashes instead of just ignoring the problem drives. Makes for a bad user experience. Would it not be better for anaconda to to just go ahead and see if it can find a drive it can work with and if not report this to the user? For example in this case there is a standard sata drive (non raid) in the machine with free space on it that can be used.

Just for informational purposes, when the backtrace is displayed to the user the user gets the option of sending it to bugzilla. With the fields filled in (un, pw etc) clicking send hangs the installer. Before the installer hangs the 'detecting storage' dialog re-appears.

I know that the code is new for this release (and it's probably too late to put things into this release) but for later releases it might be worth briefly looking at these two issues for a better user experience.


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