* Timeout waiting for /dev/md/imsm0 ?
@ 2022-08-15 22:28 David F.
2022-08-16 7:02 ` Mariusz Tkaczyk
0 siblings, 1 reply; 6+ messages in thread
From: David F. @ 2022-08-15 22:28 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
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
(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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timeout waiting for /dev/md/imsm0 ?
2022-08-15 22:28 Timeout waiting for /dev/md/imsm0 ? David F.
@ 2022-08-16 7:02 ` Mariusz Tkaczyk
2022-08-17 2:04 ` David F.
0 siblings, 1 reply; 6+ messages in thread
From: Mariusz Tkaczyk @ 2022-08-16 7:02 UTC (permalink / raw)
To: David F.; +Cc: linux-raid@vger.kernel.org
Hi David,
On Mon, 15 Aug 2022 15:28:08 -0700
"David F." <df7729@gmail.com> wrote:
> 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.
>
> (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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timeout waiting for /dev/md/imsm0 ?
2022-08-16 7:02 ` Mariusz Tkaczyk
@ 2022-08-17 2:04 ` David F.
2022-08-17 5:54 ` Hannes Reinecke
2022-08-18 8:19 ` Mariusz Tkaczyk
0 siblings, 2 replies; 6+ messages in thread
From: David F. @ 2022-08-17 2:04 UTC (permalink / raw)
To: Mariusz Tkaczyk; +Cc: linux-raid@vger.kernel.org
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.
On Tue, Aug 16, 2022 at 12:03 AM Mariusz Tkaczyk
<mariusz.tkaczyk@linux.intel.com> wrote:
>
> Hi David,
> On Mon, 15 Aug 2022 15:28:08 -0700
> "David F." <df7729@gmail.com> wrote:
>
> > 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.
> >
> > (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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timeout waiting for /dev/md/imsm0 ?
2022-08-17 2:04 ` David F.
@ 2022-08-17 5:54 ` Hannes Reinecke
2022-08-17 7:09 ` David F.
2022-08-18 8:19 ` Mariusz Tkaczyk
1 sibling, 1 reply; 6+ messages in thread
From: Hannes Reinecke @ 2022-08-17 5:54 UTC (permalink / raw)
To: David F., Mariusz Tkaczyk; +Cc: linux-raid@vger.kernel.org
On 8/17/22 04:04, David F. 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.
>
Please check the device-mapper status.
My guess is that device-mapper gets in the way (as it probably will be
activated from udev, too), and blocks the devices when mdadm is trying
to access them.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timeout waiting for /dev/md/imsm0 ?
2022-08-17 5:54 ` Hannes Reinecke
@ 2022-08-17 7:09 ` David F.
0 siblings, 0 replies; 6+ messages in thread
From: David F. @ 2022-08-17 7:09 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Mariusz Tkaczyk, linux-raid@vger.kernel.org
It turns out the cause was missing 63-md-raid-arrays.rules. It
appears 64-md-raid-assembly.rules will assemble the devices on
boot/sysinit and works even without 63-md-raid-arrays.rules, but
starting using the script needs the 63-md-raid-array.rules. Not sure
why, but that appears to be it. If I remove 64 and leave 63, the
dmraid takes over, but I can "dmsetup remove_all" then start the md
RAID with the script and it works, I can also use nodmraid and then
run the script.
So thanks for pointing me to udev - still would be curious why 64
doesn't need 63.
On Tue, Aug 16, 2022 at 10:54 PM Hannes Reinecke <hare@suse.de> wrote:
>
> On 8/17/22 04:04, David F. 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.
> >
> Please check the device-mapper status.
>
> My guess is that device-mapper gets in the way (as it probably will be
> activated from udev, too), and blocks the devices when mdadm is trying
> to access them.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Kernel Storage Architect
> hare@suse.de +49 911 74053 688
> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
> Myers, Andrew McDonald, Martje Boudien Moerman
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timeout waiting for /dev/md/imsm0 ?
2022-08-17 2:04 ` David F.
2022-08-17 5:54 ` Hannes Reinecke
@ 2022-08-18 8:19 ` Mariusz Tkaczyk
1 sibling, 0 replies; 6+ messages in thread
From: Mariusz Tkaczyk @ 2022-08-18 8:19 UTC (permalink / raw)
To: David F.; +Cc: linux-raid@vger.kernel.org
On Tue, 16 Aug 2022 19:04:02 -0700
"David F." <df7729@gmail.com> 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
> <mariusz.tkaczyk@linux.intel.com> wrote:
> >
> > Hi David,
> > On Mon, 15 Aug 2022 15:28:08 -0700
> > "David F." <df7729@gmail.com> wrote:
> >
> > > 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.
> > >
> > > (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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-08-18 8:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-15 22:28 Timeout waiting for /dev/md/imsm0 ? David F.
2022-08-16 7:02 ` Mariusz Tkaczyk
2022-08-17 2:04 ` David F.
2022-08-17 5:54 ` Hannes Reinecke
2022-08-17 7:09 ` David F.
2022-08-18 8:19 ` Mariusz Tkaczyk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).