Bug 429713

16:41:52 ERROR   : error scanning dmraid, disabling: discover_disks() takes at
most 1 argument (2 given)

Try the next build of python-pyblock and see if it works better for you.

proposing a release note since this is an Alpha blocker that didn't make it,

Hello Jon, 

The alpha blocker is already referenced from the release notes. If you need any
changes, feel free to edit the wiki at 

http://fedoraproject.org/wiki/Releases/9/Alpha/ReleaseNotes

We have three approaches to take:

1. Note specific bugs within the Releases/9/Alpha/ReleaseNotes page, or
2. Make it clear that alpha users need to check the alpha bug blocker page to
see if their bug is already known
3. 1 + 2

For the users, doing both 1 and 2 would be best.  Could be more insane to
maintain, though.

*** Bug 431851 has been marked as a duplicate of this bug. ***

Beta was released without this fixed even though it was a blocker?

Happens on Highpoint RAID1 in the PR.

dmraid -r from the shell shows valid metadata on both drives but they are not
recognized as dmraid devices.

"dmraid -ay" from the shell makes block device dm-0 (253,0) show up in
/proc/partitions

hrm, I was testing dmraid recently on my nvidia raid system and all was working
according to spec, so looks like this may be highpoint specific?  Will have to
verify again with the nvidia system.  Sadly due to device mapper shenanigans
this tends to be a bit fragile and can break shortly after testing good :/

Can someone with a highpoint RAID controller retest this? If it's still a
problem I'd like to make a note of it for F9 users.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 305430 [details]
screenshot of anaconda log and results from running dmraid manually

Still broken in F9-final...

Can you please retest this with F-10, in combination with these updates.img files:
http://people.atrpms.net/~hdegoede/updates474399-i386.img
http://people.atrpms.net/~hdegoede/updates474399-x86_64.img

To use this with an i386 install using isw "hardware" raid type the following
at the installer bootscreen (press <tab> to get to the cmdline editor):
updates=http://people.atrpms.net/~hdegoede/updates474399-i386.img

For an x86_64 install use:
updates=http://people.atrpms.net/~hdegoede/updates474399-i386.img

Please let me know if this resolves the issue for you.

Background: I have an Intel 82801 sata raid card that mirrors 2 underlying sata drives.  After a failed attempt to reinstall grub, the system booted with "Error 15" at the point where I'd expect to see grub first start to show up.  Attempts to run either the F10 x86_64 installer or rescue mode failed to convince the kernel to see the array; it recognized the individual underlying drives (which caused problems when it saw 2 separate LABEL=root devices, sda5 and sdb5.  The log terminal displayed "error scanning dmraid, disabling: isw_cbeaeedaba_ARRAY", which is how I found this report.  For reference, the system (lunkwill.dartmouth.edu, in smolt) was originally a Fedora 8, yum upgraded to Fedora 10, and successfully booted via grub for a few weeks.

I tried your updated img, Hans (note, both your URL's pointed to the i386 image, but I tried the obvious "updates=http://people.atrpms.net/~hdegoede/updates474399-x86_64.img" and it existed).  The rescue mode _does_ now successfully mount the isw_cbea... partitions (root, /home, /boot, etc) instead of the underlying disk partitions.  Thank you!

Note, before it drops me off into a shell, the installer still complains twice about "ERROR: only one argument is allowed for this option", which seemed to show up when I started having this problem of seeing more than one root partition on the underlying drives.  For reference, udevd still seems to provide direct access to /dev/sda, /dev/sdb, /dev/sdb4, /dev/sdb5, /dev/sdb7, /dev/sdb8, bot NOT any individual partitions on sda or sdb{1,2,3,6} .  Also, /mnt/sysimage/dev/ is not mounted, but this is quickly fixed with "mount --bind /dev/ /mnt/sysimage/dev/" before running chroot /mnt/sysimage/ , and running "mkdir /dev/shm ; mount /dev/shm" after entering chroot.

To successfully get grub to run, I had to follow the suggestions from comment 48 in bug 450143 (modified for my particular raid device, see /dev/mapper) and run:
grub
device (hd0,2) /dev/mapper/isw_cbeaeedaba_ARRAYp3
device (hd0) /dev/mapper/isw_cbeaeedaba_ARRAY
root (hd0,2)
setup (hd0)
quit

That cleared up "Error 15" and "Error 22r: no such partition" at the grub prompt, but the system still reboots immediately after grub shows "Grub loading Stage 1.5", and "GRUB loading, please wait".

wstearns, this bug is about highpoint motherboard raid, not isw as you have. isw is indeed broken in F-9 and F-10. And very much fixed in F-11, if you want you can give F11 beta (which will be released the coming week) a try, isw motherboard raid should work fine there.

Jesse or Chuck, can you give please F-11 a try with highpoint dmraid? Thanks!

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.