Description of problem: Get a traceback instead of a successful install. Version-Release number of selected component (if applicable): Anaconda-13.32 How reproducible: Every time Steps to Reproduce: 1. Configure a raid5 device in BIOS 2. Boot 3. Get traceback when attempting to find devices I suspect there are at least two problems here, and that this may effect more than just raid5. 1) Anaconda is ignoring --nodmraid (at least in terms of how this problem plays out). The problem observed is a failure to load a dmraid raid45 module and subsequently the inability to create the table entries and populate the set. This shouldn't be an issue if nodmraid is passed on the command line as it should skip dmraid configuration. It doesn't. 2) I suspect testing was mainly done with raid1 Intel Matrix RAID arrays, and since the raid1 dm raid module is present, this issue didn't present itself. However, if you have a raid5 or raid10 array configured in the BIOS, then it does. So, I'm guessing the module list in the installer initrd is missing some modules, or there needs to be an exception in anaconda to not attempt to initialize device mapper support for raid levels that aren't actually supported.
Created attachment 400887 [details] Anaconda traceback from run with raid5 array active
Created attachment 400888 [details] Anaconda traceback from run with raid5 array active and with --nodmraid
Created attachment 400889 [details] Output of udevadm info --export-db on box
Update: trying this with a raid1 array already created by the BIOS avoided the traceback (at least initially, I made it traceback later). However, it told me that disks sda and sdb had BIOS raid data, but are not part of any recognized BIOS raid sets. Ignoring disks sda, sdb. I'm attaching more support files from this boot with the machine in raid1 mode.
Created attachment 400900 [details] syslog from raid1 attempt
Created attachment 400901 [details] program.log from raid1 attempt
Created attachment 400902 [details] storage.log from raid1 attempt
Created attachment 400903 [details] contents of /proc/mdstat at time sda and sdb were declared not part of a raid set
Created attachment 400904 [details] kernel dmesg output
Hi Doug, Thanks for the bug report, and thanks for testing! Please file a separate bug for the RAID 1 issue. What you are seeing wrt RAID5 is caused by the filter UI (the basic / advanced storage selection screens) always using dmraid to identify BIOS RAID sets. Currently the filter UI also tries to online them using dmraid (to figure out the size), which fails as the Fedora kernel does not have support for RAID5 when using device mapper RAID. This can be fixed for Intel RAID by not activating the set (*), I'll write an anaconda patch for this. For non Intel BIOS RAID 5, we will have to release note this. *) Later on when partitioning it will get activated using mdraid. I hope to have a patch for this later today. Regards, Hans
Proposing this as an F13Blocker, as this makes installs on BIOS RAID 5 systems impossible.
Thanks Hans, unless this problem is specific to only a certain device, I think this qualifies as a F13 Beta blocker according to the beta release criteria [1]. # The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot [1] https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
The patch for this has been added to the f13-branch of anaconda, the next anaconda version: anaconda-13.37-1, will contain the fix for this. Moving to modified.
Doug, can you please test with Beta RC1 - http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.RC1/Fedora/ - and confirm this is fixed? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-13.37-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.37-1.fc13
anaconda-13.37-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.