Red Hat Bugzilla – Bug 214053
Unable to create RAID arrays on FC6 beyond /dev/md0
Last modified: 2007-11-30 17:11:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20060921 Ubuntu/dapper-security Firefox/184.108.40.206
Description of problem:
Successfully created a RAID1 on /dev/md0, but for each other RAID 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):
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
I got stuck with a system that I can't fully use. /home and /usr/local are planned to go on those RAID arrays.
I should have fully functionning RAID devices that I could mkfs and mount.
I googled around and found that this can be udev-related.
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.
Why is FC lacking these nodes? For example, they are pre-created in openSUSE, so
users don't run into spurious messages like these.
*** Bug 216438 has been marked as a duplicate of this bug. ***
KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device"
because of bug #204157
From Alasdair Kergon (firstname.lastname@example.org):
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.
sry, ignore my last comment... confused md* vs dm*
Why is this bug closed with "NOTABUG"? It is still present and should be solved
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.
Thank you for clarification and the hint with the option "--auto=yes", I was not
aware of this.