The above warning was shown while trying to install Fedora 15 TC2 from DVD. Either after choosing "basic storage" or after choosing "advanced storage" and after selecting it choosing "next".
The two disks are in a striping RAID controlled by an Intel RAID controller. There's a third disk in the system that is not part of the RAID.
I was able to always reproduce this so far. Installation is not possible like this.
I could not yet try with a LiveCD due to the well-known bug that doesn't let you start the installation from live media. Will revisit as soon as that's fixed, i.e. probably during the weekend.
Created attachment 479611 [details]
program.log from after the warning shows up
Created attachment 479612 [details]
storage.log from after the warning shows up
Created attachment 479613 [details]
syslog from after the warning shows up
Adding F15Blocker according to this test case:
...which blocks the beta release according to:
From the description of that case:
"This install verifies that installing on a BIOS RAID device works properly."
From the expected results of that case:
"1. All installable BIOS RAID devices are successfully detected by installer and are available for partitioning."
I've got to clarify/correct what I said above a little.
The warning itself won't stop the installation - but (unless I choose my third disk as a target) I won't be able to perform the installation as I have "not enough space" in the partitioning step.
*** Bug 679620 has been marked as a duplicate of this bug. ***
For the record, this still exists on Alpha RC1.
While you could (in theory) install to a drive not included in the IMSM raid, as the raid isn't assembled, and there is no mdadm on the DVD, it is not possible to install to an IMSM raid at this time.
I can confirm this bug also exists on FC14, AMD64 using the live installer. Strange because I don't use HW-raid (and never did in the past), only SW-raid.
So far I'm unable to install FC14.
I believe that this only affects the live CD on F14. Installation still works correctly from either the DVD or install CD / netinstall. As F14 isn't the latest anymore, I doubt this will get fixed for F14.
At least 14 is the latest stable release...
I already tried the dvd, but also without any luck. Will try the netinstall later, but I don't expect it to work.
On my system I am using SW raid, but it complains about 'bios raid metadata'. When opening a terminal on the live cd I am able to mount and access my sw raid partitions perfectly. Only anaconda complains.
*** Bug 681284 has been marked as a duplicate of this bug. ***
Fedora 14 installer worked for me on an Intel Bios Raid 10 set. Used final x86_64 DVD.
For Fedora 15, I see the problem this bz reports, but am able to do the install by using the mdadm.conf generated in F14, putting it in /etc in tty-2 and assembling the array (don't forget that PATH doesn't have /sbin in it yet).
Yes, this is a blocker for F15 Beta.
Created attachment 481916 [details]
Patch to fix scanning of md fwraid
I can confirm that patch (which is also part of the patch for bug 680226) to fix this issue. I then hit bug 681608, though.
Patches that (attempt to) fix all known intel firmware RAID issues for F15 are available in bug 681608 for those doing live installs. For those doing non-live installs, just ask and I'll be happy to provide an updates image for you to test with.
(In reply to comment #15)
> Patches that (attempt to) fix all known intel firmware RAID issues for F15 are
> available in bug 681608 for those doing live installs. For those doing non-live
> installs, just ask and I'll be happy to provide an updates image for you to
> test with.
Please, sir, may I have one?
(In reply to comment #16)
> (In reply to comment #15)
> > Patches that (attempt to) fix all known intel firmware RAID issues for F15 are
> > available in bug 681608 for those doing live installs. For those doing non-live
> > installs, just ask and I'll be happy to provide an updates image for you to
> > test with.
> Please, sir, may I have one?
It won't help you much at this point unless you're using the simple/basic storage path, but you can find updates against anaconda-15.20.1-1 here:
Due to limitations with the new tools used to handle the intel fwraid (mdadm), we have to use a combination of dmraid and mdadm to handle those arrays. This ends up adding a requirement that both tools agree on the name of the devices, which apparently cannot be relied upon. Working on that now...
I'll standby until a DVD image is released with these updates. That way I can test the entire solution. Are these scheduled for F15 Beta TC1 at this stage?
Fixed for Fedora 15 in anaconda-15.22-1.
I got this problem wheh I install Fedora 15 on Sony Vaio VPC z12 which have two SSD disks. But Fedora 14 is OK.
Discussed at 2011-03-11 blocker review meeting. This issue is fixed and available for testing in anaconda-15.22-1. The issue has been accepted as a beta blocker.
I tested the boot.iso made by James Laska by creating a USB key install.
The install proceeded as it should, however anaconda installed grub to /dev/sdc - which was the USB key. As such, I cannot boot to either Windows or F15 without booting off the USB key first.
# cat /etc/grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd1,3)
# kernel /boot/vmlinuz-version ro root=/dev/md127p4
# initrd /boot/initrd-[generic-]version.img
title Fedora (2.6.38-0.rc8.git0.1.fc15.x86_64)
kernel /boot/vmlinuz-2.6.38-0.rc8.git0.1.fc15.x86_64 ro root=UUID=db570be9-689a-434b-a505-74d96538166a rd_MD_UUID=0d242700:88229f97:87e814e7:870bc4de rd_MD_UUID=3981b2e3:f2e47cb0:1285fa11:ef98308b rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet
title Windows 7
# cat /boot/grub/device.map
As of this moment, I am unsure how to get grub to install on /dev/md127. The following doesn't seem to work as I would expect it to:
# grub-install /dev/md127
expr: non-integer argument
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
Pay attention to the "Boot Loader" column in the "Install Target Devices" pane on the right side of the screen that follows the one that asks you which type of partitioning you want. That's how you tell anaconda which disk to install the bootloader to.
anaconda-15.26-1.fc15 has been submitted as an update for Fedora 15.
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-15.26-1.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
anaconda-15.26-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Anaconda-15.26-1.fc15 did not fix the issue.
Fixing the issue involved going in to disk utility through a live CD and creating a new partition map (IE reformatting your drive to MBR or GPT / GUID).
This fixed my issue coming from a Windows based BIOS RAID on an AMD chipset.
Adding a "nodmraid" option to the installer's kernel command line is another workaround. Tested on Scientific Linux 6.5 and Supermicro's H8DGT-HF motherboard (AMD SP5100 chipset).