On Tue, 16 Aug 2022 19:04:02 -0700
"David F." [off-list ref] wrote:

What rules should be used?   I don't see a /dev/md directory, I
created one, stopped the raid (all the /dev/md* devices went away)
and tried to start the raid, same thing and only /dev/md127 gets
created, nothing in /dev/md/ directory and none of the md126 devices ?
 You then get the timeout.

https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/udev-md-raid-arrays.rules#n24
ENV{DEVTYPE}=="disk", ENV{MD_DEVNAME}=="?*", SYMLINK+="md/$env{MD_DEVNAME}"

The clue here is:
IMPORT{program}="BINDIR/mdadm --detail --no-devices --export $devnode"
where property MD_DEVNAME is generated. It is obtained from "/var/run/mdadm/map"
file and generally is same as name property in metadata.

It is all in udev-md-raid-arrays.rules

Mariusz

On Tue, Aug 16, 2022 at 12:03 AM Mariusz Tkaczyk
[off-list ref] wrote:

quoted

Hi David,
On Mon, 15 Aug 2022 15:28:08 -0700
"David F." [off-list ref] wrote:
 

quoted

I'm not sure if this list is getting the messages but to summarize, if
I pass the 5.15.x kernel parameter "nomdraid" to skip udev from doing
anything with the RAID and then run:

mdadm - v4.1 - 2018-10-01

mdadm --examine --scan to create the /etc/mdadm/mdadm.conf file with:

ARRAY metadata=imsm UUID=788c3635:2e37de4b:87d08323:987f57e5
ARRAY /dev/md/TestRAID container=788c3635:2e37de4b:87d08323:987f57e5
member=0 UUID=835de710:3d35bfb1:d159af46:6570f120

Then run:

mdadm --assemble --scan --no-degraded -v

I get:

mdadm: looking for devices for further assembly
mdadm: no RAID superblock on /dev/sdc1
mdadm: /dev/sdc is not attached to Intel(R) RAID controller.
mdadm: No OROM/EFI properties for /dev/sdc
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sda5
mdadm: no RAID superblock on /dev/sda3
mdadm: no RAID superblock on /dev/sda2
mdadm: no RAID superblock on /dev/sda1
mdadm: /dev/sdb is identified as a member of /dev/md/imsm0, slot 1.
mdadm: /dev/sda is identified as a member of /dev/md/imsm0, slot 0.
mdadm: added /dev/sdb to /dev/md/imsm0 as 1
mdadm: added /dev/sda to /dev/md/imsm0 as 0
mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
mdadm: timeout waiting for /dev/md/imsm0
mdadm: looking for devices for /dev/md/TestRAID
mdadm: cannot open device /dev/md/imsm0: No such file or directory
mdadm: Cannot assemble mbr metadata on /dev/sdc1
mdadm: Cannot assemble mbr metadata on /dev/sdc
mdadm: /dev/sdb has wrong uuid.
mdadm: Cannot assemble mbr metadata on /dev/sda5
mdadm: Cannot assemble mbr metadata on /dev/sda3
mdadm: Cannot assemble mbr metadata on /dev/sda2
mdadm: no recogniseable superblock on /dev/sda1
mdadm: /dev/sda has wrong uuid.
mdadm: looking for devices for /dev/md/TestRAID
mdadm: cannot open device /dev/md/imsm0: No such file or directory
mdadm: Cannot assemble mbr metadata on /dev/sdc1
mdadm: Cannot assemble mbr metadata on /dev/sdc
mdadm: /dev/sdb has wrong uuid.
mdadm: Cannot assemble mbr metadata on /dev/sda5
mdadm: Cannot assemble mbr metadata on /dev/sda3
mdadm: Cannot assemble mbr metadata on /dev/sda2
mdadm: no recogniseable superblock on /dev/sda1
mdadm: /dev/sda has wrong uuid.

If I let UDEV start it and then stop the RAID with:

mdadm --stop --scan  

No, You didn't ask udev. You asked mdadm to do clean up. It will trigger
"remove" event at some point so then udev will be involved.  

quoted

(which does stop it) then try to start again using the above command,
I still get the timeout.

This was working fine with older version 5.10.x kernel with the
following differences:

   mdadm v4.1 - 2018-10-01 (but from a different build - debian
instead of devuan)
   kmod as an older version
   udev (eudev) was built against the older kmod.
   all the various shared libraries and utilities were moved up to
versions with Devuan Chimaera
   rules updated (although I tried with the old rules too, no difference)

Any idea on what is wrong?  Any tricks to have it output more
information to diagnose what is happening?   The /dev/md127 device
gets created, the actual devices never get created, even if you wait.  

The error you mentioned in subject is caused by udev. This error means that
udev failed to create link in /dev/md/ directory.
If you are not referencing to this link, it can be ignored. We are expecting
that udev will create the link and we are waiting for it as some point in
mdadm.

Thanks,
Mariusz