From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description of problem: I have a Gigabyte 7VAXP-A Ultra M/B that comes with a Promise PDC20276 chipset. I have 2 80GB configured as RAID0 and have about 20GB of free space. I tried to install Fedora Core 3 onto this free space. When I boot Fedora Core 3 on DVD, it boots and went into anaconda graphics installer. When I come into disk partitioning, it ask me which harddisk I want to install onto. Apparently it seems to detect my RAID0 as 2 separate hard disk. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Boot Fedora Core 3 on DVD 2. 3. Actual Results: Does not detect my RAID0 as a single drive Expected Results: Detect my RAID0 as a single drive Additional info:
sounds like you configured your raid using the promise BIOS tool. Anaconda will only detect Linux software raid partitions. ISTR there's a device mapper target module to support the various raid controller disk formats, but I'm not sure of its status wrt merging. Alasdair ?
There are a lot of motherboards with Promise RAID. I hope Fedora can support these motherboards with RAID.
Dave, dmraid is the tool supporting various ATARAID formats (such as the one in this case). It reads the vendor specific metadata and converts it into device-mapper tables in order to activate respective mapped devices for each RAID set. Talked to Jeremy ysterday about the missing early boot integration of dmraid in FC>2/RHEL-4. He hasn't had the time to look at it yet.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.