This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 429713 - some dmraid devices not seen as dmraid (highpoint)
some dmraid devices not seen as dmraid (highpoint)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
NeedsRetesting
:
: 431851 (view as bug list)
Depends On:
Blocks: F9Blocker F9Alpha F9Beta
  Show dependency treegraph
 
Reported: 2008-01-22 12:01 EST by Jesse Keating
Modified: 2013-01-09 21:44 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:15:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
jonstanley: fedora_requires_release_note?


Attachments (Terms of Use)
screenshot of anaconda log and results from running dmraid manually (289.27 KB, image/jpeg)
2008-05-14 22:00 EDT, Chuck Ebbert
no flags Details

  None (edit)
Description Jesse Keating 2008-01-22 12:01:10 EST
On my nvidia based dmraid system a dmraid stripe is not seen as dm, it is seen
as individual disks.  Needless to say that after install is complete the machine
doesn't boot.

This is a test machine in my lab and can be used to reproduce whatever is needed.
Comment 1 Jesse Keating 2008-01-24 15:07:01 EST
16:41:52 ERROR   : error scanning dmraid, disabling: discover_disks() takes at
most 1 argument (2 given)
Comment 2 Chris Lumens 2008-01-24 16:11:54 EST
Try the next build of python-pyblock and see if it works better for you.
Comment 3 Jon Stanley 2008-02-01 23:12:37 EST
proposing a release note since this is an Alpha blocker that didn't make it,
Comment 4 Rahul Sundaram 2008-02-01 23:17:13 EST
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
Comment 5 Karsten Wade 2008-02-04 18:46:19 EST
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.
Comment 6 Will Woods 2008-02-07 11:34:09 EST
*** Bug 431851 has been marked as a duplicate of this bug. ***
Comment 7 Chuck Ebbert 2008-04-24 14:46:15 EDT
Beta was released without this fixed even though it was a blocker?
Comment 8 Chuck Ebbert 2008-04-24 14:47:53 EDT
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.
Comment 9 Chuck Ebbert 2008-04-24 15:01:23 EDT
"dmraid -ay" from the shell makes block device dm-0 (253,0) show up in
/proc/partitions
Comment 10 Jesse Keating 2008-04-24 19:53:41 EDT
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 :/
Comment 11 Will Woods 2008-05-09 17:35:25 EDT
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.
Comment 12 Bug Zapper 2008-05-14 00:50:12 EDT
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
Comment 13 Chuck Ebbert 2008-05-14 22:00:26 EDT
Created attachment 305430 [details]
screenshot of anaconda log and results from running dmraid manually

Still broken in F9-final...
Comment 14 Hans de Goede 2009-01-16 17:09:19 EST
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.
Comment 15 wstearns 2009-03-30 12:47:28 EDT
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".
Comment 16 Hans de Goede 2009-03-30 14:30:19 EDT
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!
Comment 17 Bug Zapper 2009-06-09 19:24:36 EDT
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
Comment 18 Bug Zapper 2009-07-14 14:15:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.