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.
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. ***
udev has: KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device" because of bug #204157 From Alasdair Kergon (agk): 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 imho.
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.