Bug 214053 - Unable to create RAID arrays on FC6 beyond /dev/md0
Unable to create RAID arrays on FC6 beyond /dev/md0
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
6
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
:
: 216438 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-05 02:05 EST by J.F.Gratton
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-05 10:43:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description J.F.Gratton 2006-11-05 02:05:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.7) Gecko/20060921 Ubuntu/dapper-security Firefox/1.5.0.7

Description of problem:
Successfully created a RAID1 on /dev/md0, but for each other RAID[01] arrays I've tried to create I get such an error message:

mdadm: error opening /dev/md1: No such file or directory
(sure enough, there is no other md devices listed in /dev besides /dev/md0)

I classified this bug as mdadm-related altought I think it might be a udev issue.

Had no such issue with FC5 or FC4

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1.mdadm -C /dev/md0 --level=1 --raid-devices=2 /dev/sd[ab]1 --> WORKS FINE
2.mdadm -C /dev/md1 --level=1 --raid-devices=2 /dev/sd[ab]2 --> bombs with the error mentioned above
3.every other combinations of /dev/mdX (besides 0), raid-level, number of devices and device names will reproduce the bug

Actual Results:
I got stuck with a system that I can't fully use. /home and /usr/local are planned to go on those RAID arrays.

Expected Results:
I should have fully functionning RAID devices that I could mkfs and mount.

Additional info:
I googled around and found that this can be udev-related.
Comment 1 Doug Ledford 2006-11-05 10:43:23 EST
This isn't a bug in mdadm.  The devices simply don't exist.  They must be
created first.  You can manually create them, or you can pass the --auto=yes
flag to mdadm when creating the arrays and it will make the device nodes for you.
Comment 2 Jan Engelhardt 2007-01-30 06:24:21 EST
Why is FC lacking these nodes? For example, they are pre-created in openSUSE, so
users don't run into spurious messages like these.
Comment 3 Harald Hoyer 2007-01-30 07:39:45 EST
*** Bug 216438 has been marked as a duplicate of this bug. ***
Comment 4 Harald Hoyer 2007-01-30 07:44:40 EST
udev has:
KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device"
because of bug #204157

From Alasdair Kergon (agk@redhat.com):
udev needs to completely ignore the 'add' event, and instead act on the 'change'
event.  Until the change event arrives under no circumstances should udev
attempt to open the dm device or query any dm device properties.  In future lvm2
and other applications will then wait until udev has completed processing the
'change' event before proceeding.  udev will then be able to assume full
responsibility for /dev/mapper - the 'change' event will cause the nodes to be
added to /dev.  There is no way to do this correctly in response to the existing
'add' event, because the dm properties udev needs to query are not yet defined
in-kernel at this point.  The 'change' event is the new signal that the
properties are now fully defined.
Comment 5 Harald Hoyer 2007-01-30 07:49:50 EST
sry, ignore my last comment... confused md* vs dm*
Comment 6 Peter Bieringer 2007-03-04 03:34:58 EST
Why is this bug closed with "NOTABUG"? It is still present and should be solved
imho.
Comment 7 Doug Ledford 2007-03-05 10:48:00 EST
It's close NOTABUG because there is no bug.  The change from a normal, fully
populated /dev directory to a udev controlled directory was done to clean up all
the useless entries.  Pre-populating the directory would be counterproductive
towards that original goal.  This means that for some activities, specifically
ones involving virtual devices that the kernel can't automatically probe, a
slightly different method of system administration is now needed.  The sysadmin
of these systems simply needs to pass the --auto=yes option to mdadm on the same
command they use to create the device.
Comment 8 Peter Bieringer 2007-03-06 11:51:04 EST
Thank you for clarification and the hint with the option "--auto=yes", I was not
aware of this.

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