Device Unusable At Startup

Device Unusable At Startup

[Jake Thomas]

First of all, I have no idea if this e-mail address is a part of a
mailing list, so please CC me individually, or somehow reply to me
personally.

My goal: create a RAID 1 array between a partition on the hard drive
and a ramdisk and mount this md array at /usr. Once poplulated, the
vast majority of my programs will run out of RAM, and be very fast! I
have 8 GB of RAM, so why not?


On startup, the partition, which is a linux_raid_member, is detected
as such, and /dev/md127 is automatically created.

The problem: /dev/md127 is not usable. "sudo blkid /dev/md127" yeilds
nothing. mdadm can't even query anything about it.

Since this is RAID _one_ it should be able to function just fine with
only one member, but it doesn't.

In fact, to get it going again, I have to do:

sudo mdadm --stop /dev/md127
sudo mdadm -A /dev/md127 -f /dev/sda2

#works at this point, now to add in the ramdisk:
sudo mdadm /dev/md127 -a /dev/ram0


Then "sudo blkid /dev/md127" says that it's ext4 formatted, that it
has a UUID, etc., and it is usable. After mounting it after fixing it,
all my data is there.

Problem restated: /usr needs to be mounted so early in startup that
there is no script that I can have automate the fixing of my /usr RAID
device in time for it to be mounted when it needs to be. I shouldn't
even have to do that. It should just be functional from the get-go.

I have a thread going on about this here:
http://bbs.archbang.org/viewtopic.php?id=3179 .

I have even tried renaming /sbin/mdadm to /sbin/mdadm.moved and doing
"sudo /sbin/mdadm.moved --stop --scan" before shutdown, as mentioned
here: http://neil.brown.name/blog/20120615073245#6 . After restart,
the automatically generated md device for the found linux_raid_member
partition is still unusable.

I have tried both kernel 3.3.4-1-ARCH with mdadm 3.2.3-2 and kernel
3.4.7-1 with mdadm 3.2.5-2.

The original idea for this came from here:
https://bbs.archlinux.org/viewtopic.php?pid=493773#p493773 . I, of
course, can't afford enough RAM to put the entirety of my installation
in RAM, but I can afford to put /usr entirely in RAM.

Can any of you folks help me out on this?

Cheers,
Jake

Re: Device Unusable At Startup

[Jake Thomas]

CC to linux-raid mailing list:

Hi Neil!

   Sorry for the delayed response. I kept checking on my iPhone for a
response, and for some reason or lack thereof didn't see it. I figured
that I'd have to wait a few days for my post to go through. I started
checking over here everyday and never got a response:
http://marc.info/?l=linux-raid&m=134415164808677&w=2 . I guess I
neglected this blog. And I was out camping for a few days.

   When I do "sudo /sbin/mdadm.moved -D /dev/md127" after startup
(before it's working), it says:

mdadm: md device /dev/md127 does not appear to be active.

(I now moved /sbin/mdadm.moved back to /sbin/mdadm for ease of use.)

When I do "sudo mdadm --misc --query /dev/md127", I get:

/dev/md127: is an md device which is not active


I found out that I can do:

"sudo mdadm -R /dev/md127" and that starts it up just fine and
everything is good again. (Don't have to stop it or anything.)

I can then do:
sudo mdadm /dev/md127 -a /dev/ram0.

However, the problem still remains that it is not started on start-up,
thus I cannot have /usr be such a raid device, which needs to be
mounted very early in startup, before any scripts get ran. Therefore I
can't just put "mdadm -R /dev/md127" in a script somewhere to fix the
issue. I even tried the raid=autodetect option at the kernel
parameters line (And yes, "mdadm_udev" was in the HOOKS line in
mkinitcpio.conf and "md_mod" and "raid0" were in the MODULES line in
mkinitcpio.conf when I built the initial ramdisk with mkinitcpio.)
I also tried doing "md=1,/dev/sda2" at the kernel line, which was
ignored, because /dev/md1 was not created. Instead, I got the regular
/dev/md127 (which is not active). Also tried "md=1,/dev/sda2,missing".
Same result. Also tried "md=1,/dev/sda2,/dev/ram0". Same result. Also
tried "md=1,/dev/ram0,/dev/sda2". Same result. Also tried
"md=1,missing,/dev/sda2". Same result.
I also tried  md-mod.start_dirty_degraded=1. Still wasn't active on startup.

After running the above two commands (before the kernel parameters
paragraph) to get the raid device going, "sudo mdadm -D /dev/md127"
gives:
/dev/md127:
        Version : 1.2
  Creation Time : Wed Aug  1 19:33:20 2012
     Raid Level : raid1
     Array Size : 3144692 (3.00 GiB 3.22 GB)
  Used Dev Size : 3144692 (3.00 GiB 3.22 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sun Aug 12 13:39:56 2012
          State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 9% complete

           Name : archbang:0
           UUID : 31f0bda6:4cd69924:46a0e3b2:4f7e32ba
         Events : 166

    Number   Major   Minor   RaidDevice State
       2       1        0        0      spare rebuilding   /dev/ram0
       1       8        2        1      active sync writemostly   /dev/sda2


Also, when I first startup, if I do:
sudo mdadm --manage /dev/md127 --remove /dev/sda2

I get:
mdadm: cannot get array info for /dev/md127

And if I do:
sudo mdadm --manage /dev/md* --remove /dev/sda2

I get:
mdadm: Must give one of -a/-r/-f for subsequent devices at /dev/md127

What's going on with the above two command outputs?


I will put a copy of this reply here:
http://marc.info/?l=linux-raid&m=134415164808677&w=2

For those of you looking at the linux-raid mailing list, I am coming
from here: http://neil.brown.name/blog/20120615073245 .

The idea of RAID1ing with a ramdisk came from
here:https://bbs.archlinux.org/viewtopic.php?pid=493773#p493773 .

Cheers,
Jake

Re: Device Unusable At Startup

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 4705 bytes --]

On Sun, 12 Aug 2012 15:17:09 -0700 Jake Thomas <thomasj10@georgefox.edu>
wrote:

> CC to linux-raid mailing list:
> 
> Hi Neil!
> 
>    Sorry for the delayed response. I kept checking on my iPhone for a
> response, and for some reason or lack thereof didn't see it. I figured
> that I'd have to wait a few days for my post to go through. I started
> checking over here everyday and never got a response:
> http://marc.info/?l=linux-raid&m=134415164808677&w=2 . I guess I
> neglected this blog. And I was out camping for a few days.
> 
>    When I do "sudo /sbin/mdadm.moved -D /dev/md127" after startup
> (before it's working), it says:
> 
> mdadm: md device /dev/md127 does not appear to be active.
> 
> (I now moved /sbin/mdadm.moved back to /sbin/mdadm for ease of use.)
> 
> When I do "sudo mdadm --misc --query /dev/md127", I get:
> 
> /dev/md127: is an md device which is not active
> 
> 
> I found out that I can do:
> 
> "sudo mdadm -R /dev/md127" and that starts it up just fine and
> everything is good again. (Don't have to stop it or anything.)
> 
> I can then do:
> sudo mdadm /dev/md127 -a /dev/ram0.
> 
> However, the problem still remains that it is not started on start-up,
> thus I cannot have /usr be such a raid device, which needs to be
> mounted very early in startup, before any scripts get ran. Therefore I
> can't just put "mdadm -R /dev/md127" in a script somewhere to fix the
> issue. I even tried the raid=autodetect option at the kernel
> parameters line (And yes, "mdadm_udev" was in the HOOKS line in
> mkinitcpio.conf and "md_mod" and "raid0" were in the MODULES line in
> mkinitcpio.conf when I built the initial ramdisk with mkinitcpio.)
> I also tried doing "md=1,/dev/sda2" at the kernel line, which was
> ignored, because /dev/md1 was not created. Instead, I got the regular
> /dev/md127 (which is not active). Also tried "md=1,/dev/sda2,missing".
> Same result. Also tried "md=1,/dev/sda2,/dev/ram0". Same result. Also
> tried "md=1,/dev/ram0,/dev/sda2". Same result. Also tried
> "md=1,missing,/dev/sda2". Same result.
> I also tried  md-mod.start_dirty_degraded=1. Still wasn't active on startup.
> 
> After running the above two commands (before the kernel parameters
> paragraph) to get the raid device going, "sudo mdadm -D /dev/md127"
> gives:
> /dev/md127:
>         Version : 1.2
>   Creation Time : Wed Aug  1 19:33:20 2012
>      Raid Level : raid1
>      Array Size : 3144692 (3.00 GiB 3.22 GB)
>   Used Dev Size : 3144692 (3.00 GiB 3.22 GB)
>    Raid Devices : 2
>   Total Devices : 2
>     Persistence : Superblock is persistent
> 
>     Update Time : Sun Aug 12 13:39:56 2012
>           State : clean, degraded, recovering
>  Active Devices : 1
> Working Devices : 2
>  Failed Devices : 0
>   Spare Devices : 1
> 
>  Rebuild Status : 9% complete
> 
>            Name : archbang:0
>            UUID : 31f0bda6:4cd69924:46a0e3b2:4f7e32ba
>          Events : 166
> 
>     Number   Major   Minor   RaidDevice State
>        2       1        0        0      spare rebuilding   /dev/ram0
>        1       8        2        1      active sync writemostly   /dev/sda2
> 
> 
> Also, when I first startup, if I do:
> sudo mdadm --manage /dev/md127 --remove /dev/sda2
> 
> I get:
> mdadm: cannot get array info for /dev/md127
> 
> And if I do:
> sudo mdadm --manage /dev/md* --remove /dev/sda2
> 
> I get:
> mdadm: Must give one of -a/-r/-f for subsequent devices at /dev/md127
> 
> What's going on with the above two command outputs?
> 
> 
> I will put a copy of this reply here:
> http://marc.info/?l=linux-raid&m=134415164808677&w=2
> 
> For those of you looking at the linux-raid mailing list, I am coming
> from here: http://neil.brown.name/blog/20120615073245 .
> 
> The idea of RAID1ing with a ramdisk came from
> here:https://bbs.archlinux.org/viewtopic.php?pid=493773#p493773 .




If you ask a question on the blog, you get a reply on the blog. If you ask a question on linux-raid you get a reply on linux-raid.... If you ask on both.... :-) 

The array isn't starting at boot time because it is degraded. This suggests a problem
with the boot scripts. I suspect your distro ('arch'?) is relying on "mdadm -I"
being run from udev to start the arrays. This by itself isn't always enough. After
all devices have been discovered you need "mdadm -Irs" or "mdadm --incremental --run --scan"
to assemble any newly-degraded arrays.

So in some script before it tries to mount filesystems you want something like:

   udevadm settle mdadm --incremental --run --scan

This will have to go in a script in the initrd of course.


NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Device Unusable At Startup

[Jake Thomas]

sudo mdadm --create /dev/answers --level=1 --raid-devices=2
/dev/blog,/dev/linux-raid@vger.kernel.org

Thanks for the responses Neil!

   I did try the following kernel parameter:

md-mod.start_dirty_degraded=1

   Does my kernel simply not honor that parameter? I'll try and look
into my initial ramdisk and see some of these scripts you're talking
about.

Ok, I'll post more after I look at what you talked about.

Jake

Re: Device Unusable At Startup

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Sun, 12 Aug 2012 16:59:25 -0700 Jake Thomas <thomasj10@georgefox.edu>
wrote:

> sudo mdadm --create /dev/answers --level=1 --raid-devices=2
> /dev/blog,/dev/linux-raid@vger.kernel.org

;-)

> 
> Thanks for the responses Neil!
> 
>    I did try the following kernel parameter:
> 
> md-mod.start_dirty_degraded=1
> 
>    Does my kernel simply not honor that parameter? I'll try and look
> into my initial ramdisk and see some of these scripts you're talking
> about.

That parameter is for a different issue.  Starting a RAID5 or RAID6 when it
is dirty and degraded can cause data loss, so it is not done by default.

In your situation the array is not dirty and it isn't RAID5 or RAID6, so that
doesn't apply.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Device Unusable At Startup

[Jake Thomas]

Neil, you wouldn't believe it! I got it working!

Here's what I did:
I got to the Grub menu, hit "e" to temporarily edit my menu entry, and
added "break=premount" to the kernel (linux) line. This causes Linux
to drop you to a recovery shell before the real root is mounted (still
in the initial ramdisk). From there I did "mdadm -R /dev/md127". That
started /dev/md127. Then I entered "exit" to continue the booting
process.

Once fully booted, /dev/md127 no longer was active, even though I got
it active in the pre-mount environment.

From a "regular" (after the real root is mounted) environment, I ran
"sudo mdadm -R /dev/md127". This resulted in:
mdadm: failed to run array /dev/md127: Invalid argument

Then I restarted without doing a break, and "sudo mdadm -R /dev/md127"
resulted with the same error as last time.

Then I re-created the raid device with:
sudo mdadm --stop /dev/md127
(note that the file /dev/md127 still exists, it's just stopped, which
I find interesting.)
sudo mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sda2 missing

Then I stopped all devices:

sudo mdadm --stop /dev/md127

(I only had that one device. I probably could have done "sudo mdadm
--stop /dev/md* if I really wanted to wipe them all out, if I had
more.)

Then I renamed mdadm to mdadm.moved:
sudo mv /sbin/mdadm /sbin/mdadm.moved

Then I restarted:
sudo shutdown -r 0

And my ramdisk hybrid raid device was up and running after startup!

One time I didn't stop /dev/md127 and restarted. That corrupted it.

I remade it, and as long as I stopped the device before shutdown, I was good.

Going into the pre-mount environment does not seem to be needed to
make it _NOT_ corrupted, but I wanted to tell the story how it was.


I changed fstab to use the raid device for /usr (specifying by uuid!),
added "/sbin/mdadm.moved --stop /dev/md*" very early in
/etc/rc.shutdown, and added "/sbin/mdadm.moved /dev/disk/by-uuid/[uuid
of my hybrid md device] -a /dev/ram0" to /etc/rc.local.

And now it works!

Yey!!!! Thanks so much Neil Brown and Mr. Green and all y'all!

Super Cheers,
Jake

Re: Device Unusable At Startup

[Jake Thomas]

P.S. That was weird because I remembered trying renaming mdadm and
stopping all md devices before shutdown (which you suggested at your
blog), but that didn't work the first time I tried it.

Maybe the key was totally re-creating the array (which I thought I
did) using "missing" (ah, the "missing" part could be the key here?!).

The only thing I think I did differently is use "missing" when I
re-created the array. I even remember using "missing" before, but
apparently, I just didn't get the right six numbers.

Cheers,
Jake

On Sun, Aug 12, 2012 at 11:45 PM, Jake Thomas <thomasj10@georgefox.edu> wrote:
> Neil, you wouldn't believe it! I got it working!
>
> Here's what I did:
> I got to the Grub menu, hit "e" to temporarily edit my menu entry, and
> added "break=premount" to the kernel (linux) line. This causes Linux
> to drop you to a recovery shell before the real root is mounted (still
> in the initial ramdisk). From there I did "mdadm -R /dev/md127". That
> started /dev/md127. Then I entered "exit" to continue the booting
> process.
>
> Once fully booted, /dev/md127 no longer was active, even though I got
> it active in the pre-mount environment.
>
> From a "regular" (after the real root is mounted) environment, I ran
> "sudo mdadm -R /dev/md127". This resulted in:
> mdadm: failed to run array /dev/md127: Invalid argument
>
> Then I restarted without doing a break, and "sudo mdadm -R /dev/md127"
> resulted with the same error as last time.
>
> Then I re-created the raid device with:
> sudo mdadm --stop /dev/md127
> (note that the file /dev/md127 still exists, it's just stopped, which
> I find interesting.)
> sudo mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sda2 missing
>
> Then I stopped all devices:
>
> sudo mdadm --stop /dev/md127
>
> (I only had that one device. I probably could have done "sudo mdadm
> --stop /dev/md* if I really wanted to wipe them all out, if I had
> more.)
>
> Then I renamed mdadm to mdadm.moved:
> sudo mv /sbin/mdadm /sbin/mdadm.moved
>
> Then I restarted:
> sudo shutdown -r 0
>
> And my ramdisk hybrid raid device was up and running after startup!
>
> One time I didn't stop /dev/md127 and restarted. That corrupted it.
>
> I remade it, and as long as I stopped the device before shutdown, I was good.
>
> Going into the pre-mount environment does not seem to be needed to
> make it _NOT_ corrupted, but I wanted to tell the story how it was.
>
>
> I changed fstab to use the raid device for /usr (specifying by uuid!),
> added "/sbin/mdadm.moved --stop /dev/md*" very early in
> /etc/rc.shutdown, and added "/sbin/mdadm.moved /dev/disk/by-uuid/[uuid
> of my hybrid md device] -a /dev/ram0" to /etc/rc.local.
>
> And now it works!
>
> Yey!!!! Thanks so much Neil Brown and Mr. Green and all y'all!
>
> Super Cheers,
> Jake

Re: Device Unusable At Startup

[Jake Thomas]

Sorry for the lateness of this note, but I've been rather busy at
school (and still am).

Although in my previous post, I did say I got the array working (not
as /usr, but rather at a non-system-critical mount point),
and also working whilst mounted at /usr,

I cannot unmount it if it is mounted as /usr (and thus couldn't stop
it), because /usr is in use (duh). Not even if I put it late in a
shutdown script.
Therefore, due to the bug, it gets corrupted on shutdown.

When it wasn't at /usr, I could stop the device before shutdown,
keeping it from being corrupted.

When it was mounted at /usr, there was nothing I could do to stop it
from being corrupted at shutdown, though I did get it
working before I shutdown.

To get into it again, I specify the break=premount kernel parameter
and forcably reassemble the array and fsck the
filesystem on it from the premount commandline.

Then I exit the premount commandline, and it boots on its merry way.



To automate this, I made a custom hook:

"P.P.S. Sorry it took so long for this note. I've been (and still am)
rather busy at school. Due to the current mdadm bug, I found it
nessecary to make a custom hook that assembles and fs checks the raid
array, premount.
The problem is that the array gets broken on shutdown due to a bug in
mdadm. Therefore /usr can't get mounted on startup, unless you boot
into a Live environment or something and fix the raid array in there
(or just specify the break=premount kernel parameter and fix from the
premount commandline).
This wouldn't happen if the array is stopped before shutdown (and
/sbin/mdadm is moved to /sbin/mdadm.moved), but since /usr is in use
till the very end, it can't be stopped. So it gets broke every
shutdown.

Fortunately, a custom hook (which you add to mkinitcpio.conf, and then
re-make the initial ramdisk with) can automate the forced assembly and
fs checking of the array, all premount. So it breaks on shutdown, and
fixes itself on startup.

I followed the Arch Wiki's howto for making custom hooks. But here's
the quick-and-clean solution:

I put this in a file named "mdusr_fixer" in the
/usr/lib/initcpio/install folder:

[code]
#!/bin/bash

build()
{
	#mdadm binary already added by other stuff
	add_runscript
}

help ()
{
	cat <<HELPOF
Fixes borked md array holding /usr. On shutdown, the
md array holding my /usr filesystem gets broke, due
to a bug in mdadm. If the array was stopped before
shutdown, it wouldn't get broke. But it can't be
stopped. So I'm fixinig it on startup, premount.
HELPOF
}
[/code]

And this into a file named "mdusr_fixer" in the /usr/lib/initcpio/hooks folder:

[code]
#! /usr/bin/ash

run_hook ()
{
	msg -n ":: About to fix broke md array holding /usr"

	msg -n ":: Stopping all md devices. Sorry, it must be done."

	msg -n ":: It's the only way I can stop the broke md array, which I
have to do to fix it."

	msg -n ":: You'll have to manually start any non-/usr md devices, or
script them elsewhere."

	mdadm --stop /dev/md*

	mdadm --assemble --run /dev/md0 /dev/disk/by-id/ata-ST31500341AS_9VS51LLD-part2

	fsck -f /dev/md0

	msg -n ":: Done fixing /usr md device."
}
[/code]

Before we can re-assemble the broken array, we must stop it.

Note that all md devices must be stopped using a wildcard: "/dev/md*"
because we technically don't know
for sure what the name of the md device is that holds /usr. It could
be /dev/md127, /dev/md126, /dev/md125
or whatever. We simply don't know. If it's the only md device present,
it will, with almost 100% certainty, be /dev/md127,
but what if someone plugs in USB drives that have mdraid before you
turn the computer on? Now we really don't know.
Or, more likely, if you have more than one md raid array amongst your
internal hard drives, we wouldn't know the name of the one we must
stop to reassemble.

Unfortunately, /dev/disk/by-uuid is not populated for this md device,
because it is currently broke. So we can't specify it by uuid
or anything. A system-wide stopping of all md devices (/dev/md*) must
be done to stop it.

Now to assemble it, we must specify the partition that holds half the
raid1 array. How? Not simply by saying /dev/sda2.
That can change from boot-to-boot. So the next best thing is to
specify by uuid (/dev/disk/by-uuid/[blah blah blah]).
But unfortunately, /dev/disk/by-uuid is not populated for
linux_raid_member formatted partitions, (the partition itself, not the
filesystem it contains).

So we have to resort to /dev/disk/by-id/[hardware-based name of hard
drive, hyphen, "part", partition number].
And that works great!

Now run fsck on the md device you just reassembled. This can be
refered to as /dev/md0, rather than by some jumble-proof reference,
because we just explicitly named it /dev/md0.

And, of course, I added mdusr_fixer to the HOOKS line in
mkinitcpio.conf, and re-made the the initial ramdisk with mkinitcpio."

From: http://bbs.archbang.org/viewtopic.php?pid=17316#p17316 .

Cheers,
Jake

Re: Device Unusable At Startup

[Jan Ceuleers]

On 09/28/2012 01:47 AM, Jake Thomas wrote:
> Note that all md devices must be stopped using a wildcard: "/dev/md*"
> because we technically don't know
> for sure what the name of the md device is that holds /usr. It could
> be /dev/md127, /dev/md126, /dev/md125
> or whatever. We simply don't know. If it's the only md device present,
> it will, with almost 100% certainty, be /dev/md127,
> but what if someone plugs in USB drives that have mdraid before you
> turn the computer on? Now we really don't know.
> Or, more likely, if you have more than one md raid array amongst your
> internal hard drives, we wouldn't know the name of the one we must
> stop to reassemble.
> 
> Unfortunately, /dev/disk/by-uuid is not populated for this md device,
> because it is currently broke. So we can't specify it by uuid
> or anything. A system-wide stopping of all md devices (/dev/md*) must
> be done to stop it.

Would it be a fair expectation for any non-borked arrays to be numbered
starting at /dev/md0 ? So that only the arrays numbered above 100 to be
likely borked?

If so you could try limiting the mdadm --stop to only /dev/md1[0-9][0-9]
or something like that.

HTH, Jan

Re: Device Unusable At Startup

[Jake Thomas]

Well, all automatically generated md devices are numbered from md127 down.

You may have some manually specified md devices going from md0 up (such as via kernel parameters or scripts).

Either one of those two categories may contain working md arrays.

So, since there very well could be automatically generated _working_ md devices in the "high range", no, you can't assume that all working md devices are in the low range.

Thanks for the "range syntax" tip. I didn't know about it.


Also note that in my particular situation, md0 does not exist until after I stop the borked array.

Jake

Sent from my iPhone

On Sep 28, 2012, at 4:11 AM, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 09/28/2012 01:47 AM, Jake Thomas wrote:
>> Note that all md devices must be stopped using a wildcard: "/dev/md*"
>> because we technically don't know
>> for sure what the name of the md device is that holds /usr. It could
>> be /dev/md127, /dev/md126, /dev/md125
>> or whatever. We simply don't know. If it's the only md device present,
>> it will, with almost 100% certainty, be /dev/md127,
>> but what if someone plugs in USB drives that have mdraid before you
>> turn the computer on? Now we really don't know.
>> Or, more likely, if you have more than one md raid array amongst your
>> internal hard drives, we wouldn't know the name of the one we must
>> stop to reassemble.
>> 
>> Unfortunately, /dev/disk/by-uuid is not populated for this md device,
>> because it is currently broke. So we can't specify it by uuid
>> or anything. A system-wide stopping of all md devices (/dev/md*) must
>> be done to stop it.
> 
> Would it be a fair expectation for any non-borked arrays to be numbered
> starting at /dev/md0 ? So that only the arrays numbered above 100 to be
> likely borked?
> 
> If so you could try limiting the mdadm --stop to only /dev/md1[0-9][0-9]
> or something like that.
> 
> HTH, Jan

Re: Device Unusable At Startup

[Jan Ceuleers]

On 09/28/2012 02:12 PM, Jake Thomas wrote:
> Thanks for the "range syntax" tip. I didn't know about it.

Two question marks would probably also do it, since those characters are
unlikely to be anything other than digits. So /dev/md1??

> Sent from my iPhone

Doesn't excuse top-posting on a mailing list tho...

Jan