Created attachment 627472 [details] anaconda.log Description of problem: I tried to install Fedora on BIOS RAID, but it's not shown on harddrive screen. Version-Release number of selected component (if applicable): Fedora 18-Beta-TC4 x86_64 anaconda 18.16 How reproducible: Always
Created attachment 627473 [details] blkid
Created attachment 627474 [details] mdstat
Created attachment 627476 [details] program.log
Created attachment 627477 [details] storage.log
Created attachment 627484 [details] syslog
Created attachment 627489 [details] wipefs /dev/sda
Created attachment 627491 [details] wipefs /dev/sdb
Created attachment 627493 [details] wipefs /dev/sdc
Created attachment 627494 [details] wipefs /dev/sdd
Discussed at 2012-10-15 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-10-15/fedora-qa.2012-10-15-15.00.log.txt . We agreed we need more testing to determine blocker status of this bug - whether it affects more BIOS RAID configs or just this specific one. anaconda team, if you could comment on that it'd help. Michal, if you could provide more details about your hardware and the exact BIOS RAID config that would also help. It would also help to know what you see on the custom partitioning screen, if you can even get there. I will test this myself this week and see what I come up with. From storage.log it looks like this is Intel BIOS RAID and it sure looks like the storage code recognizes it, so this may be a UI issue with the new disk selector screen not knowing how to display BIOS RAID arrays.
The fwraid array isn't getting detected correctly. We can see that it's there, but the process of scanning it does not complete successfully: 09:24:26,915 DEBUG storage: looking up parted Device: /dev/md/imsm0 09:24:26,916 DEBUG storage: no device or no media present We have switched to using the named device nodes for md arrays for f18, so it may be related to that.
hardware: INTEL ICH10R/DO SATA RAID Controller,4 harddrives configuration: 1. and 4. harddrives are not members of RAID, 2. and 3. are RAID1 members. I can see only 1. and 4. harddrives on harddrive screen. I reassembled RAID and tried 2 different configurations. RAID5: 2.,3. and 4. harddrives are RAID5 members. I can see only 1. harddrive on hardrive screen. cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] md126 : active raid5 sdb[2] sdc[1] sdd[0] 976768000 blocks super external:/md127/0 level 5, 64k chunk, algorithm 0 [3/3] [UUU] [>....................] resync = 2.8% (13683648/488384128) finish=165.2min speed=47876K/sec md127 : inactive sdb[2](S) sdc[1](S) sdd[0](S) 7356 blocks super external:imsm unused devices: <none> RAID10: all harddrives are RAID10 members. I see no harddrives on harddrive screen. cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] md126 : active raid10 sda[3] sdb[2] sdc[1] sdd[0] 625137664 blocks super external:/md127/0 64K chunks 2 near-copies [4/4] [UUUU] [==>..................] resync = 14.5% (90901632/625137920) finish=67.6min speed=131690K/sec md127 : inactive sdb[3](S) sdd[2](S) sda[1](S) sdc[0](S) 11719 blocks super external:imsm unused devices: <none>
Created attachment 628002 [details] storage.log for RAID5
Created attachment 628003 [details] storage.log for RAID10
Discussed at 2012-10-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-17/f18beta-blocker-review-4.2012-10-17-16.00.log.txt . The new information from Michal is useful and indicates that all configs with his controller are not being handled correctly, it's not just one bad config, but we agreed we'd like at least one other person to confirm that Intel BIOS RAID is not properly recognized on another system before accepting this as a blocker, so the determination is delayed for now.
I just tried installing to a bare metal system using a 2 disk intel RAID1 array using smoke9 (anaconda-18.16.1). The RAID array does not show up as an available installation target. I booted the F17 installer on the same system and the RAID array does show up as an available target. Since this does affect plain RAID configs, I'm +1 blocker per the F18 beta release criterion [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] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
+1 blocker now we know it affects more than one setup.
I'm confirming I see this on my laptop too, FWIW. My laptop has two SSDs in a BIOS RAID-0 configuration (yes, Sony are crazy), it doesn't show on the disk picker screen at all. It's Intel BIOS RAID like Michal's system, the device shows as /dev/md126pX . I can attach logs if needed, but I figure Michal's should be enough.
I did some debugging of this with dlehman today, it's not a simple fix and he'll keep working on it.
(In reply to comment #16) > Since this does affect plain RAID configs, I'm +1 blocker per the F18 beta > release criterion [1]: I don't think this does affect plain RAID. The trigger seems to be the presence of a partition table on the md device.
Discussed at 2012-10-22 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-10-22/fedora-qa.2012-10-22-15.00.html . Accepted as a blocker per criterion "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".
Someone please try this updates image and attach logs (storage, program, syslog): http://dlehman.fedorapeople.org/updates/updates-866519.4.img The updates were made against anaconda-18.21-1 but might still work against 18.19-1.
No visible difference, device still doesn't show up in the Disk Picker. Attaching desired logs. Tested with smoke12 and the updates.img above.
Created attachment 634056 [details] storage.log from 18.21+updates4
Created attachment 634058 [details] program.log from 18.21+updates4
Created attachment 634059 [details] syslog from 18.21+updates4
New updates image: http://dlehman.fedorapeople.org/updates/updates-866519.5.img
Causes anaconda to crash. http://fpaste.org/bTOO/
With http://dlehman.fedorapeople.org/updates/updates-866519.6.img (which finally exists), Intel FW raid arrays (at least my two) finally show up on the disk picker. Testing on my desktop, with a RAID-0 array of 2x80GB disks, after picking 'BIOS RAID set (stripe)' and hitting 'Continue', the 'Installation Destination' spoke still has the warning triangle, and when I go back into it, I still see the RAID set there, but I also see a banner at the bottom of the screen saying "No disks detected. Please shut down the computer, connect at least one disk, and restart to complete installation', and the 'Continue' button never seems to be un-greyed no matter what I do with the disk selection. I see three disks - the RAID set, the USB stick I'm booting from (which is in itself a bug), and a 0 byte 'phantom' disk anaconda has always seen on this system (I think it's something to do with the card reader in my floppy bay). Whichever of these I select or unselect, the button never goes active. If I unselect the RAID array and click 'Done', the hub cycles back to 'No disks selected' for 'Installation Destination'. I can click on it again and again, I see the three disks but also the 'No disks detected' banner, and whatever disks I select, I can't hit Continue. So I can only hit Continue on the disk picker screen once, and it doesn't actually leave me in an installable state. No way to proceed with install that I can find. Will attach logs.
Created attachment 635220 [details] storage.log after unsuccessful attempt at a RAID install
Created attachment 635221 [details] storage.state after unsuccessful attempt at a RAID install with updates6
Created attachment 635222 [details] program.log after unsuccessful attempt at a RAID install with updates6
Created attachment 635223 [details] syslog after unsuccessful attempt at a RAID install with updates6
New updates image: http://dlehman.fedorapeople.org/updates/updates-866519.7.img
That makes it all the way to initiating install (on a very straightforward 'pick the RAID array, click Continue, click OK, continue with install' path) and crashes there. Attaching logs.
Created attachment 635739 [details] storage.log after unsuccessful attempt at a RAID install with updates7
Created attachment 635740 [details] program.log after unsuccessful attempt at a RAID install with updates7
Created attachment 635743 [details] syslog after unsuccessful attempt at a RAID install with updates7
Created attachment 635744 [details] storage.state after unsuccessful attempt at a RAID install with updates7
Created attachment 635747 [details] traceback from crash at start of install with updates7
For the record, at this point we run into a parted issue: <dlehman> bcl: in case you're busy or afk, I'm wondering about parted support for named md device nodes in /dev/md/. they're pretty much equivalent to /dev/mapper/ device nodes, which parted supports/uses. if you create a parted device w/ path=/dev/mapper/whatever then later device.path will be /dev/mapper/whatever, but if you do it w/ path=/dev/md/whatever then access device.path you get /dev/mdXpY, which anaconda doesn't like. bcl: for beta we're going to have fix one end or the other, and the anaconda end is a pretty ugly fix. this may be the point at which we should close this bug (well, put the fixes so far into 18.22 and consider it fixed by 18.22) and open a new one, we're quite a long way away from the initial territory now, and in a different component.
I have split out the parted issue as https://bugzilla.redhat.com/show_bug.cgi?id=872361 . We can consider this one modified once dlehman commits the changes that at least make the disk picker screen properly detect and offer fw RAID arrays as valid targets - the stuff that went into updates7.
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
Package anaconda-18.23-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.23-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17509/anaconda-18.23-1.fc18 then log in and leave karma (feedback).
I confirmed that this bug, so far as it goes, is fixed in 18.23. The array appears in the disk picker. Further bugs are https://bugzilla.redhat.com/show_bug.cgi?id=872361 and https://bugzilla.redhat.com/show_bug.cgi?id=872739 .
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
Package anaconda-18.24-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.24-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17543/anaconda-18.24-1.fc18 then log in and leave karma (feedback).
VERIFIED that this is fixed in TC7.
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
Package anaconda-18.25-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.25-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17691/anaconda-18.25-1.fc18 then log in and leave karma (feedback).
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Package anaconda-18.26-1.fc18, lorax-18.22-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.26-1.fc18 lorax-18.22-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17714/lorax-18.22-1.fc18,anaconda-18.26-1.fc18 then log in and leave karma (feedback).
Still fixed in TC7.
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).