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.
Created attachment 346765 [details] anaconda.log
Created attachment 346766 [details] Storage.log
Created attachment 346767 [details] Dmraid output
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.
Hi, 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).
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. cheers Rehan