Description of problem: My system contains 2 SATA drives -- sda and sdb. sda is partitioned as follows: Device Boot Start End Blocks Id System /dev/sda1 1 1044 8385898+ 7 HPFS/NTFS /dev/sda2 * 1045 1063 152617+ fd Linux raid autodetect /dev/sda3 1064 1082 152617+ fd Linux raid autodetect /dev/sda4 1083 60801 479692867+ f W95 Ext'd (LBA) /dev/sda5 1083 7054 47970058+ fd Linux raid autodetect /dev/sda6 7055 13026 47970058+ fd Linux raid autodetect /dev/sda7 13027 18998 47970058+ fd Linux raid autodetect /dev/sda8 18999 24970 47970058+ fd Linux raid autodetect /dev/sda9 24971 30942 47970058+ fd Linux raid autodetect /dev/sda10 30943 36914 47970058+ fd Linux raid autodetect /dev/sda11 36915 42886 47970058+ fd Linux raid autodetect /dev/sda12 42887 48858 47970058+ fd Linux raid autodetect /dev/sda13 48859 54830 47970058+ fd Linux raid autodetect /dev/sda14 54831 60801 47962026 fd Linux raid autodetect sdb is partitioned identically, except that sdb1 is an ext3 filesystem, rather than NTFS. I have 12 software RAID-1 devices. md0 consists of sda2 and sdb2, md1 consists of sda3 and sdb3, through md11 which consists of sda14 and sdb14. None of the RAID devices contains a partition table. md0 (sda2 and sdb2) is an ext3 filesystem which serves as /boot for 64-bit operating systems (/boot64). md1 is an ext3 filesystem which serves as /boot for 32-bit operating systems (/boot32). grub is installed in the boot sector of both /boot64 and /boot32, and each can chainload the other. The remainder of the RAID devices (md2 - md11) are LVM PVs. They are all part of a single VG (home_vg). home_vg contains 14 LVs -- root filesystems for various versions/flavors of Linux, swap, etc. anaconda has not been able to handle this setup since the Fedora 11(?) storage rewrite. I was getting a traceback, but that has now been fixed in rawhide. The installation now simply hangs, with the GUI showing the "Finding storage devices" popup. VT3 shows numerous "DEBUG: mdX state is clear" messages, followed by the following: 14:29:23 INFO : moving(1) to step findrootparts [2009-08-14 14:29:23,227] DEBUG: md0 state is clear [2009-08-14 14:29:23,231] DEBUG: md0 state is clear ps shows that PID 8008 is in state "D+": mdadm --assemble /dev/md0 --uuid=... --run --audo=md --update=super-minor /dev/sda2 /dev/sdb2 (I have verified with "mdadm -E" that the UUID is correct; I don't feel like re-typing it.) dmesg shows the following: INFO: task mdadm:8008 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. mdadm D 0000000000000001 4664 8008 356 0x00000080 ffff880112c05938 0000000000000086 ffff880112d5c978 0000000000000001 ffff880112d5c940 0000000000000007 0000000000000006 ffff88010e8d4628 ffff880112d5cd30 000000000000fa20 ffff880112d5cd30 00000000001d5bc0 Call Trace: [<ffffffff814fb156>] ? __mutex_lock_common+0x20e/0x3bf [<ffffffff81096546>] ? trace_hardirqs_on_caller+0x139/0x175 [<ffffffff8116ed21>] ? revalidate_disk+0x5e/0x9d [<ffffffff814fb166>] __mutex_lock_common+0x21e/0x3bf [<ffffffff8116ed21>] ? revalidate_disk+0x5e/0x9d [<ffffffff814fb42a>] mutex_lock_nested+0x4f/0x6b [<ffffffff8116ed21>] revalidate_disk+0x5e/0x9d [<ffffffff813f35ce>] do_md_run+0x886/0x92f [<ffffffff814fb356>] ? mutex_lock_interruptible_nested+0x4f/0x6a [<ffffffff813f5f30>] md_ioctl+0x11b6/0x142b [<ffffffff81095fab>] ? mark_lock+0x3c/0x253 [<ffffffff81263f12>] __blkdev_driver_ioctl+0x36/0x95 [<ffffffff81264895>] blkdev_ioctl+0x8d6/0x925 [<ffffffff8101aa23>] ? native_sched_clock+0x2d/0x62 [<ffffffff8122bae6>] ? __rcu_read_unlock+0x34/0x4a [<ffffffff8122ca90>] ? avc_has_perm_noaudit+0x3c9/0x3ef [<ffffffff8122cb21>] ? avc_has_perm+0x6b/0x91 [<ffffffff8116e5b4>] block_ioctl+0x4a/0x62 [<ffffffff81150e03>] vfs_ioctl+0x31/0xaa [<ffffffff811513c5>] do_vfs_ioctl+0x4aa/0x506 [<ffffffff81151486>] sys_ioctl+0x65/0x9c [<ffffffff81012f42>] system_call_fastpath+0x16/0x1b 2 locks held by mdadm/8008: #0: (&new->reconfig_mutex#2){+.+.+.}, at: [<ffffffff813edcab>] mddev_lock+0x2a/0x40 #1: (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff8116ed21>] revalidate_disk+0x5e/0x9d (All of the above was typed manually, so there may be a typo or two.) Version-Release number of selected component (if applicable): anaconda 12.14 (14-Aug-2009 rawhide). How reproducible: 100% Steps to Reproduce: 1. Attempt to install rawhide (14-Aug-2009) on system with this storage setup. Actual results: anaconda hangs in findrootparts. Expected results: No hang. Install proceeds. Additional info:
Booting with 'nosmp' gets me a little farther. (This is a dual-core system.) It appears that md0 and md1 get started successfully, but mdadm hangs trying to start md2. The same message/backtrace appears in dmesg.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.