RE: How to recreate a dmraid RAID array with mdadm
> OnTue, 23 Nov 2010 10:11:29 +1100 wrote:> > I see the problem now. And John Robinson was nearly there. > > The problem is that after assembling the container /dev/md/imsm, > mdadm needs to assemble the RAID1, but doesn't find the > container /dev/md/imsm to assemble it from. > That is because of the > DEVICE partitions > line. > A container is not a partition - it does not appear in /proc/partitions. > You need > > DEVICE partitions containers > > which is the default if you don't have a DEVICE line (and I didn't have a > device line in my testing). > > I think all the "wrong uuid" messages were because the device was busy (and > so it didn't read a uuid), probably because you didn't "mdadm -Ss" first. > > So just remove the "DEVICE partitions" line, or add " containers" to it, and > all should be happy. > > NeilBrown > Yes thank you, that seems to be the correct fix. mdadm -Asvv mdadm: looking for devices for further assembly mdadm: no RAID superblock on /dev/dm-3 mdadm: /dev/dm-3 has wrong uuid. mdadm: no RAID superblock on /dev/dm-2 mdadm: /dev/dm-2 has wrong uuid. mdadm: no RAID superblock on /dev/dm-1 mdadm: /dev/dm-1 has wrong uuid. mdadm: no RAID superblock on /dev/dm-0 mdadm: /dev/dm-0 has wrong uuid. mdadm: no RAID superblock on /dev/loop0 mdadm: /dev/loop0 has wrong uuid. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm: /dev/sdc7 has wrong uuid. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm: /dev/sdc6 has wrong uuid. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm: /dev/sdc5 has wrong uuid. mdadm: no RAID superblock on /dev/sdc2 mdadm: /dev/sdc2 has wrong uuid. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm: /dev/sdc1 has wrong uuid. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm: /dev/sdc has wrong uuid. 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 -1. mdadm: added /dev/sda to /dev/md/imsm0 as -1 mdadm: added /dev/sdb to /dev/md/imsm0 as -1 mdadm: Container /dev/md/imsm0 has been assembled with 2 drives mdadm: looking for devices for /dev/md/OneTB-RAID1-PV mdadm: no recogniseable superblock on /dev/dm-3 mdadm/dev/dm-3 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-2 mdadm/dev/dm-2 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-1 mdadm/dev/dm-1 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-0 mdadm/dev/dm-0 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/loop0 mdadm/dev/loop0 is not a container, and one is required. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm/dev/sdc7 is not a container, and one is required. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm/dev/sdc6 is not a container, and one is required. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm/dev/sdc5 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/sdc2 mdadm/dev/sdc2 is not a container, and one is required. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm/dev/sdc1 is not a container, and one is required. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm/dev/sdc is not a container, and one is required. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm/dev/sdb is not a container, and one is required. mdadm: cannot open device /dev/sda: Device or resource busy mdadm/dev/sda is not a container, and one is required. mdadm: looking in container /dev/md127 mdadm: found match on member /md127/0 in /dev/md127 mdadm: Started /dev/md/OneTB-RAID1-PV with 2 devices <-- The line I was looking for ls -al /dev/md/ total 0 drwxr-xr-x 2 root root 80 Nov 23 09:47 . drwxr-xr-x 21 root root 3480 Nov 23 09:47 .. lrwxrwxrwx 1 root root8 Nov 23 09:47 imsm0 -> ../md127 lrwxrwxrwx 1 root root8 Nov 23 09:47 OneTB-RAID1-PV -> ../md126 I filed a bug[1] as I was just going along with default configurations, to see what is said about it. Thanks soo much for your help Neil :) [1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604702 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w292469b105a527bfd32aa0ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm
I see the problem now. And John Robinson was nearly there.
The problem is that after assembling the container /dev/md/imsm,
mdadm needs to assemble the RAID1, but doesn't find the
container /dev/md/imsm to assemble it from.
That is because of the
DEVICE partitions
line.
A container is not a partition - it does not appear in /proc/partitions.
You need
DEVICE partitions containers
which is the default if you don't have a DEVICE line (and I didn't have a
device line in my testing).
I think all the "wrong uuid" messages were because the device was busy (and
so it didn't read a uuid), probably because you didn't "mdadm -Ss" first.
So just remove the "DEVICE partitions" line, or add " containers" to it, and
all should be happy.
NeilBrown
On Mon, 22 Nov 2010 13:07:10 -0500
Mike Viau wrote:
>
> > On Thu, 18 Nov 2010 16:38:49 +1100 wrote:
> > > > On Thu, 18 Nov 2010 14:17:18 +1100 wrote:
> > > > >
> > > > > > On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > > > > > > ./mdadm -Ss
> > > > > > >
> > > > > > > mdadm: stopped /dev/md127
> > > > > > >
> > > > > > >
> > > > > > > ./mdadm -Asvvv
> > > > > > >
> > > > > > > mdadm: looking for devices for further assembly
> > > > > > > mdadm: no RAID superblock on /dev/dm-3
> > > > > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > > > > Segmentation fault
> > > > > >
> > > > > > Try this patch instead please.
> > > > >
> > > > > Applied new patch and got:
> > > > >
> > > > > ./mdadm -Ss
> > > > >
> > > > > mdadm: stopped /dev/md127
> > > > >
> > > > >
> > > > > ./mdadm -Asvvv
> > > > > mdadm: looking for devices for further assembly
> > > > > mdadm: no RAID superblock on /dev/dm-3
> > > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > > tst=0x10dd010 sb=(nil)
> > > > > Segmentation fault
> > > >
> > > > Sorry... I guess I should have tested it myself..
> > > >
> > > > The
> > > > if (tst) {
> > > >
> > > > Should be
> > > >
> > > > if (tst && content) {
> > > >
> > >
> > > Apply update and got:
> > >
> > > 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 -1.
> > > mdadm: added /dev/sda to /dev/md/imsm0 as -1
> > > mdadm: added /dev/sdb to /dev/md/imsm0 as -1
> > > mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
> > > mdadm: looking for devices for /dev/md/OneTB-RAID1-PV
> >
> > So just to clarify.
> >
> > With the Debian mdadm, which is 3.1.4, if you
> >
> > mdadm -Ss
> > mdadm -Asvv
> >
> > it says (among other things) that /dev/sda has wrong uuid.
> > and doesn't start the array.
>
> Actually both compiled and Debian do not start the array. Or atleast create
> the /dev/md/OneTB-RAID1-PV device when running mdadm -I /dev/md/imsm0 does.
>
> You are right about seeing a message on /dev/sda about having a wrong uuid
> somewhere though. I went back to take a look at my output from the Debian
> mailing list to see that the mdadm did change slightly from this thread has
> begun.
>
> The old output was copied verbatim on
> http://lists.debian.org/debian-user/2010/11/msg01234.html and says (among
> other things) that /dev/sda has wrong uuid.
>
> The /dev/sd[ab] has wrong uuid messages are missing from the mdadm -Asvv
> output but
>
> ./mdadm -Ivv /dev/md/imsm0
> mdadm: UUID differs from /dev/md/OneTB-RAID1-PV.
> mdadm: match found for member 0
> mdadm: Started /dev/md/OneTB-RAID1-PV with 2 devices
>
>
> I still have this UUID message when still using the mdadm -I command.
>
>
> I'll attach the output of both the mdadm commands above as they run now on
> the system, but I noticed, but also that in the same thread link above, with
> the old output I was inqurying as to both /dev/sda and /dev/sdb (the drives
> which make up the raid1 array) do not appear to recognized as having a valid
> container when one is required.
>
> What is take on GeraldCC (gcsgcatl...@bigpond.com) assistance about
> /dev/sd[ab] containing a 8e (for LVM) partition type, rather than the fd type
> to denote raid autodetect. If this was the magical fix (which I am not saying
> it can’t be) why is mdadm -I /dev/md/imsm0 able to bring up the array for use
> as an physical volume for LVM?
>
>
>
> >
> > But with the mdadm you compiled yourself, which is also 3.1.4,
> > if you
> >
> > mdadm -Ss
> > mdadm -Asvv
> >
> > then it doesn't give that message, and it works.
>
> Again, actually both compiled and Debian do not start the array. Or atleast
> create the /dev/md/OneTB-RAID1-PV device when running mdadm -I
> /dev/md/imsm0 does.
>
> >
> > That is very strange. It seems that the Debian mdadm is broken somehow, but
> > I'm fairly sure Debian hardly changes anything - they are *very* good at
> > getting their changes upstream first.
> >
> > I don't suppose you have an /etc/mdadm.conf as well as /etc/mdadm/mdadm.conf
> > do you? If you did and the two were
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 16:38:49 +1100 wrote:
> > > On Thu, 18 Nov 2010 14:17:18 +1100 wrote:
> > > >
> > > > > On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > > > > > ./mdadm -Ss
> > > > > >
> > > > > > mdadm: stopped /dev/md127
> > > > > >
> > > > > >
> > > > > > ./mdadm -Asvvv
> > > > > >
> > > > > > mdadm: looking for devices for further assembly
> > > > > > mdadm: no RAID superblock on /dev/dm-3
> > > > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > > > Segmentation fault
> > > > >
> > > > > Try this patch instead please.
> > > >
> > > > Applied new patch and got:
> > > >
> > > > ./mdadm -Ss
> > > >
> > > > mdadm: stopped /dev/md127
> > > >
> > > >
> > > > ./mdadm -Asvvv
> > > > mdadm: looking for devices for further assembly
> > > > mdadm: no RAID superblock on /dev/dm-3
> > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > tst=0x10dd010 sb=(nil)
> > > > Segmentation fault
> > >
> > > Sorry... I guess I should have tested it myself..
> > >
> > > The
> > > if (tst) {
> > >
> > > Should be
> > >
> > > if (tst && content) {
> > >
> >
> > Apply update and got:
> >
> > 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 -1.
> > mdadm: added /dev/sda to /dev/md/imsm0 as -1
> > mdadm: added /dev/sdb to /dev/md/imsm0 as -1
> > mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
> > mdadm: looking for devices for /dev/md/OneTB-RAID1-PV
>
> So just to clarify.
>
> With the Debian mdadm, which is 3.1.4, if you
>
> mdadm -Ss
> mdadm -Asvv
>
> it says (among other things) that /dev/sda has wrong uuid.
> and doesn't start the array.
Actually both compiled and Debian do not start the array. Or atleast create the
/dev/md/OneTB-RAID1-PV device when running mdadm -I /dev/md/imsm0 does.
You are right about seeing a message on /dev/sda about having a wrong uuid
somewhere though. I went back to take a look at my output from the Debian
mailing list to see that the mdadm did change slightly from this thread has
begun.
The old output was copied verbatim on
http://lists.debian.org/debian-user/2010/11/msg01234.html and says (among other
things) that /dev/sda has wrong uuid.
The /dev/sd[ab] has wrong uuid messages are missing from the mdadm -Asvv output
but
./mdadm -Ivv /dev/md/imsm0
mdadm: UUID differs from /dev/md/OneTB-RAID1-PV.
mdadm: match found for member 0
mdadm: Started /dev/md/OneTB-RAID1-PV with 2 devices
I still have this UUID message when still using the mdadm -I command.
I'll attach the output of both the mdadm commands above as they run now on the
system, but I noticed, but also that in the same thread link above, with the
old output I was inqurying as to both /dev/sda and /dev/sdb (the drives which
make up the raid1 array) do not appear to recognized as having a valid
container when one is required.
What is take on GeraldCC (gcsgcatl...@bigpond.com) assistance about /dev/sd[ab]
containing a 8e (for LVM) partition type, rather than the fd type to denote
raid autodetect. If this was the magical fix (which I am not saying it can’t
be) why is mdadm -I /dev/md/imsm0 able to bring up the array for use as an
physical volume for LVM?
>
> But with the mdadm you compiled yourself, which is also 3.1.4,
> if you
>
> mdadm -Ss
> mdadm -Asvv
>
> then it doesn't give that message, and it works.
Again, actually both compiled and Debian do not start the array. Or atleast
create the /dev/md/OneTB-RAID1-PV device when running mdadm -I
/dev/md/imsm0 does.
>
> That is very strange. It seems that the Debian mdadm is broken somehow, but
> I'm fairly sure Debian hardly changes anything - they are *very* good at
> getting their changes upstream first.
>
> I don't suppose you have an /etc/mdadm.conf as well as /etc/mdadm/mdadm.conf
> do you? If you did and the two were different, the Debian's mdadm would
> behave a bit differently to upstream (they prefer different config files) but
> I very much doubt that is the problem.
>
There is no /etc/mdadm.conf on the filesystem only /etc/mdadm/mdadm.conf
> But I guess if the self-compiled one works (even when you take the patch
> out), then just
> make install
I wish this was the case...
>
> and be happy.
>
> NeilBrown
>
>
> >
> >
> > Full output at: http://paste.debian.net/100103/
> > expires:
> >
> > 2010-11-21 06:07:30
Thanks
-M
Compiled version
./mdadm -Ss
mdadm: stopped /dev/md127
===
./mdadm -Asvv
mdadm: looking for devices for further assembly
mdadm: no RAID superblock on /dev/dm-3
mdadm: /dev/dm-3 has wrong uuid.
want UUID-084b969a:0808f5b8:6c784fb7:62659383
tst=0x982010 sb=(nil)
mdadm: no RAID superblock on /dev/dm-2
mdadm: /dev/dm-2 has wrong uuid.
want UUID-084b969a:0808f5b8:6c784fb7:62659383
tst=0x982120 sb=(nil)
mdadm: no RAID superblock on /dev/dm-1
mdadm: /dev/dm-1 has wrong uuid.
want UUI
Re: How to recreate a dmraid RAID array with mdadm
On Thu, 18 Nov 2010 00:10:50 -0500
Mike Viau wrote:
>
> > On Thu, 18 Nov 2010 14:17:18 +1100 wrote:
> > >
> > > > On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > > > > ./mdadm -Ss
> > > > >
> > > > > mdadm: stopped /dev/md127
> > > > >
> > > > >
> > > > > ./mdadm -Asvvv
> > > > >
> > > > > mdadm: looking for devices for further assembly
> > > > > mdadm: no RAID superblock on /dev/dm-3
> > > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > > Segmentation fault
> > > >
> > > > Try this patch instead please.
> > >
> > > Applied new patch and got:
> > >
> > > ./mdadm -Ss
> > >
> > > mdadm: stopped /dev/md127
> > >
> > >
> > > ./mdadm -Asvvv
> > > mdadm: looking for devices for further assembly
> > > mdadm: no RAID superblock on /dev/dm-3
> > > mdadm: /dev/dm-3 has wrong uuid.
> > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > tst=0x10dd010 sb=(nil)
> > > Segmentation fault
> >
> > Sorry... I guess I should have tested it myself..
> >
> > The
> > if (tst) {
> >
> > Should be
> >
> > if (tst && content) {
> >
>
> Apply update and got:
>
> 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 -1.
> mdadm: added /dev/sda to /dev/md/imsm0 as -1
> mdadm: added /dev/sdb to /dev/md/imsm0 as -1
> mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
> mdadm: looking for devices for /dev/md/OneTB-RAID1-PV
So just to clarify.
With the Debian mdadm, which is 3.1.4, if you
mdadm -Ss
mdadm -Asvv
it says (among other things) that /dev/sda has wrong uuid.
and doesn't start the array.
But with the mdadm you compiled yourself, which is also 3.1.4,
if you
mdadm -Ss
mdadm -Asvv
then it doesn't give that message, and it works.
That is very strange. It seems that the Debian mdadm is broken somehow, but
I'm fairly sure Debian hardly changes anything - they are *very* good at
getting their changes upstream first.
I don't suppose you have an /etc/mdadm.conf as well as /etc/mdadm/mdadm.conf
do you? If you did and the two were different, the Debian's mdadm would
behave a bit differently to upstream (they prefer different config files) but
I very much doubt that is the problem.
But I guess if the self-compiled one works (even when you take the patch
out), then just
make install
and be happy.
NeilBrown
>
>
> Full output at: http://paste.debian.net/100103/
> expires:
>
> 2010-11-21 06:07:30
> -M
>
>
>
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101118163849.7e63b...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 12:18:13 +1000 wrote: > > Hi, > I am just starting to use RAID on my systems and it was suggested that I make > sure my drives were set to raid by: "fdisk -l" > This should say that the relavent drives are set to "raid auto-detect". > Gerald > > Where do you check "raid auto-detect" from fdisk? fdisk -v fdisk (util-linux-ng 2.17.2) fdisk -l /dev/md/OneTB-RAID1-PV Disk /dev/md/OneTB-RAID1-PV: 1000.2 GB, 1000202043392 bytes 255 heads, 63 sectors/track, 121600 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/md/OneTB-RAID1-PV1 1 121600 976751968+ 8e Linux LVM Also note that fdisk -l /dev/md/imsm0 returns nothing -M -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w531bc61891b54bdc8cd34ef...@phx.gbl
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 14:17:18 +1100 wrote:
> >
> > > On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > > > ./mdadm -Ss
> > > >
> > > > mdadm: stopped /dev/md127
> > > >
> > > >
> > > > ./mdadm -Asvvv
> > > >
> > > > mdadm: looking for devices for further assembly
> > > > mdadm: no RAID superblock on /dev/dm-3
> > > > mdadm: /dev/dm-3 has wrong uuid.
> > > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > > Segmentation fault
> > >
> > > Try this patch instead please.
> >
> > Applied new patch and got:
> >
> > ./mdadm -Ss
> >
> > mdadm: stopped /dev/md127
> >
> >
> > ./mdadm -Asvvv
> > mdadm: looking for devices for further assembly
> > mdadm: no RAID superblock on /dev/dm-3
> > mdadm: /dev/dm-3 has wrong uuid.
> > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > tst=0x10dd010 sb=(nil)
> > Segmentation fault
>
> Sorry... I guess I should have tested it myself..
>
> The
> if (tst) {
>
> Should be
>
> if (tst && content) {
>
Apply update and got:
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 -1.
mdadm: added /dev/sda to /dev/md/imsm0 as -1
mdadm: added /dev/sdb to /dev/md/imsm0 as -1
mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
mdadm: looking for devices for /dev/md/OneTB-RAID1-PV
Full output at: http://paste.debian.net/100103/
expires:
2010-11-21 06:07:30
-M
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/bay148-w508672292a737e86be8332ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm
On Thursday, November 18, 2010 10:11:49 am Neil Brown wrote: > On Wed, 17 Nov 2010 17:36:23 -0500 > > Mike Viau wrote: > > > On Wed, 17 Nov 2010 14:15:14 +1100 wrote: > > > > > > This looks wrong. mdadm should be looking for the container as listed > > > in mdadm.conf and it should find a matching uuid on sda and sdb, but > > > it doesn't. > > > > > > Can you: > > > > > > mdadm -E /dev/sda /dev/sdb ; cat /etc/mdadm/mdadm.conf > > > > > > so I can compare the uuids? > > > > Sure. > > > > # definitions of existing MD arrays ( So you don't have to scroll down :P > > ) > > > > > > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > > > > ARRAY /dev/md/OneTB-RAID1-PV > > container=084b969a:0808f5b8:6c784fb7:62659383 member=0 > > UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > > > >UUID : 084b969a:0808f5b8:6c784fb7:62659383 > > [OneTB-RAID1-PV]: > >UUID : ae4a1598:72267ed7:3b34867b:9c56497a > > > > > # definitions of existing MD arrays > > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > > ARRAY /dev/md/OneTB-RAID1-PV > > container=084b969a:0808f5b8:6c784fb7:62659383 member=0 > > UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > Yes, the uuids are definitely all correct. > This really should work. I just tested a similar config and it worked > exactly as exported. > Weird. > > Whatever version of mdadm are you running??? > Can you try getting the latest (3.1.4) from > http://www.kernel.org/pub/linux/utils/raid/mdadm/ > > and see how that works. > Just > make > ./mdadm -Asvv > > NeilBrown Hi, I am just starting to use RAID on my systems and it was suggested that I make sure my drives were set to raid by: "fdisk -l" This should say that the relavent drives are set to "raid auto-detect". Gerald -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201011181218.13724.gcsgcatl...@bigpond.com
Re: How to recreate a dmraid RAID array with mdadm
On Wed, 17 Nov 2010 22:03:41 -0500
Mike Viau wrote:
>
> > On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > > ./mdadm -Ss
> > >
> > > mdadm: stopped /dev/md127
> > >
> > >
> > > ./mdadm -Asvvv
> > >
> > > mdadm: looking for devices for further assembly
> > > mdadm: no RAID superblock on /dev/dm-3
> > > mdadm: /dev/dm-3 has wrong uuid.
> > > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > > Segmentation fault
> >
> > Try this patch instead please.
>
> Applied new patch and got:
>
> ./mdadm -Ss
>
> mdadm: stopped /dev/md127
>
>
> ./mdadm -Asvvv
> mdadm: looking for devices for further assembly
> mdadm: no RAID superblock on /dev/dm-3
> mdadm: /dev/dm-3 has wrong uuid.
> want UUID-084b969a:0808f5b8:6c784fb7:62659383
> tst=0x10dd010 sb=(nil)
> Segmentation fault
Sorry... I guess I should have tested it myself..
The
if (tst) {
Should be
if (tst && content) {
NeilBrown
>
>
> Again tried various buffer sizes (segfault above was with char buf[200];)
>
>
> if (ident->uuid_set && (!update || strcmp(update, "uuid")!= 0) &&
> (!tst || !tst->sb ||
> same_uuid(content->uuid, ident->uuid, tst->ss->swapuuid)==0)) {
> if (report_missmatch) {
> char buf[1<<16];
> fprintf(stderr, Name ": %s has wrong uuid.\n",
> devname);
> fprintf(stderr, " want %s\n", __fname_from_uuid(ident->uuid, 0,
> buf, ':'));
> fprintf(stderr, " tst=%p sb=%p\n", tst, tst?tst->sb:NULL);
> if (tst) {
> fprintf(stderr, " have %s\n",
> __fname_from_uuid(content->uuid, 0, buf, ':'));
> fprintf(stderr, " metadata=%s\n", tst->ss->name);
> }
> }
> goto loop;
> }
>
>
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101118141718.44c18...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 13:32:47 +1100 wrote:
> > ./mdadm -Ss
> >
> > mdadm: stopped /dev/md127
> >
> >
> > ./mdadm -Asvvv
> >
> > mdadm: looking for devices for further assembly
> > mdadm: no RAID superblock on /dev/dm-3
> > mdadm: /dev/dm-3 has wrong uuid.
> > want UUID-084b969a:0808f5b8:6c784fb7:62659383
> > Segmentation fault
>
> Try this patch instead please.
Applied new patch and got:
./mdadm -Ss
mdadm: stopped /dev/md127
./mdadm -Asvvv
mdadm: looking for devices for further assembly
mdadm: no RAID superblock on /dev/dm-3
mdadm: /dev/dm-3 has wrong uuid.
want UUID-084b969a:0808f5b8:6c784fb7:62659383
tst=0x10dd010 sb=(nil)
Segmentation fault
Again tried various buffer sizes (segfault above was with char buf[200];)
if (ident->uuid_set && (!update || strcmp(update, "uuid")!= 0) &&
(!tst || !tst->sb ||
same_uuid(content->uuid, ident->uuid, tst->ss->swapuuid)==0)) {
if (report_missmatch) {
char buf[1<<16];
fprintf(stderr, Name ": %s has wrong uuid.\n",
devname);
fprintf(stderr, " want %s\n", __fname_from_uuid(ident->uuid, 0, buf,
':'));
fprintf(stderr, " tst=%p sb=%p\n", tst, tst?tst->sb:NULL);
if (tst) {
fprintf(stderr, " have %s\n",
__fname_from_uuid(content->uuid, 0, buf, ':'));
fprintf(stderr, " metadata=%s\n", tst->ss->name);
}
}
goto loop;
}
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/bay148-w494b0f5eb60cc742dfc817ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm
On Wed, 17 Nov 2010 21:05:40 -0500
Mike Viau wrote:
> ./mdadm -Ss
>
> mdadm: stopped /dev/md127
>
>
> ./mdadm -Asvvv
>
> mdadm: looking for devices for further assembly
> mdadm: no RAID superblock on /dev/dm-3
> mdadm: /dev/dm-3 has wrong uuid.
> want UUID-084b969a:0808f5b8:6c784fb7:62659383
> Segmentation fault
Try this patch instead please.
NeilBrown
diff --git a/Assemble.c b/Assemble.c
index afd4e60..11e6238 100644
--- a/Assemble.c
+++ b/Assemble.c
@@ -344,9 +344,17 @@ int Assemble(struct supertype *st, char *mddev,
if (ident->uuid_set && (!update || strcmp(update, "uuid")!= 0)
&&
(!tst || !tst->sb ||
same_uuid(content->uuid, ident->uuid,
tst->ss->swapuuid)==0)) {
- if (report_missmatch)
+ if (report_missmatch) {
+ char buf[200];
fprintf(stderr, Name ": %s has wrong uuid.\n",
devname);
+ fprintf(stderr, " want %s\n",
__fname_from_uuid(ident->uuid, 0, buf, ':'));
+ fprintf(stderr, " tst=%p sb=%p\n", tst,
tst?tst->sb:NULL);
+ if (tst) {
+ fprintf(stderr, " have %s\n",
__fname_from_uuid(content->uuid, 0, buf, ':'));
+ fprintf(stderr, " metadata=%s\n",
tst->ss->name);
+ }
+ }
goto loop;
}
if (ident->name[0] && (!update || strcmp(update, "name")!= 0) &&
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101118133247.7ffa9...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 12:28:47 +1100 wrote:
> >
> > I am running the same version, from a Debian Squeeze package which I
> > presume is the same.
> >
> > mdadm -V
> >
> > mdadm - v3.1.4 - 31st August 2010
>
> Yes, should be identical to what I am running.
> >
> > >
> > > and see how that works.
> > > Just
> > > make
> > > ./mdadm -Asvv
> >
> > Regardless, I did recompile (attached is the make output -- no errors) and
> > got similar mdadm output:
> >
> > ./mdadm -Asvv
> > mdadm: looking for devices for further assembly
> > mdadm: no RAID superblock on /dev/md126p1
> > mdadm: /dev/md126p1 has wrong uuid.
> > mdadm: no RAID superblock on /dev/md/OneTB-RAID1-PV
> > mdadm: /dev/md/OneTB-RAID1-PV has wrong uuid
>
> > mdadm: cannot open device /dev/sdb: Device or resource busy
> > mdadm: /dev/sdb has wrong uuid.
> > mdadm: cannot open device /dev/sda: Device or resource busy
> > mdadm: /dev/sda has wrong uuid.
>
> The arrays are clearly currently assembled. Trying to assemble them again is
> not likely to produce a good result :-) I should have said to "./mdadm -Ss"
> first.
>
> Could you apply this patch and then test again with:
>
> ./mdadm -Ss
> ./mdadm -Asvvv
>
Applied the patch:
if (ident->uuid_set && (!update || strcmp(update, "uuid")!= 0) &&
(!tst || !tst->sb ||
same_uuid(content->uuid, ident->uuid,
tst->ss->swapuuid)==0)) {
if (report_missmatch) {
char buf[200];
fprintf(stderr, Name ": %s has wrong uuid.\n",
devname);
fprintf(stderr, " want %s\n",
__fname_from_uuid(ident->uuid, 0, buf, ':'));
fprintf(stderr, " have %s\n",
__fname_from_uuid(content->uuid, 0, buf, ':'));
fprintf(stderr, " metadata=%s\n", tst->ss->name);
}
goto loop;
}
And got:
./mdadm -Ss
mdadm: stopped /dev/md127
./mdadm -Asvvv
mdadm: looking for devices for further assembly
mdadm: no RAID superblock on /dev/dm-3
mdadm: /dev/dm-3 has wrong uuid.
want UUID-084b969a:0808f5b8:6c784fb7:62659383
Segmentation fault
I took the liberty of extending the char buffer to 2000 bytes/chars and 64K
(1<<16) but got the same segfaults.
-M
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/bay148-w149179108dc6d340247236ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm
On Wed, 17 Nov 2010 19:56:10 -0500
Mike Viau wrote:
> I am running the same version, from a Debian Squeeze package which I presume
> is the same.
>
> mdadm -V
>
> mdadm - v3.1.4 - 31st August 2010
Yes, should be identical to what I am running.
>
> >
> > and see how that works.
> > Just
> > make
> > ./mdadm -Asvv
>
> Regardless, I did recompile (attached is the make output -- no errors) and
> got similar mdadm output:
>
> ./mdadm -Asvv
> mdadm: looking for devices for further assembly
> mdadm: no RAID superblock on /dev/md126p1
> mdadm: /dev/md126p1 has wrong uuid.
> mdadm: no RAID superblock on /dev/md/OneTB-RAID1-PV
> mdadm: /dev/md/OneTB-RAID1-PV has wrong uuid
> mdadm: cannot open device /dev/sdb: Device or resource busy
> mdadm: /dev/sdb has wrong uuid.
> mdadm: cannot open device /dev/sda: Device or resource busy
> mdadm: /dev/sda has wrong uuid.
The arrays are clearly currently assembled. Trying to assemble them again is
not likely to produce a good result :-) I should have said to "./mdadm -Ss"
first.
Could you apply this patch and then test again with:
./mdadm -Ss
./mdadm -Asvvv
Thanks,
NeilBrown
diff --git a/Assemble.c b/Assemble.c
index afd4e60..11323fa 100644
--- a/Assemble.c
+++ b/Assemble.c
@@ -344,9 +344,14 @@ int Assemble(struct supertype *st, char *mddev,
if (ident->uuid_set && (!update || strcmp(update, "uuid")!= 0)
&&
(!tst || !tst->sb ||
same_uuid(content->uuid, ident->uuid,
tst->ss->swapuuid)==0)) {
- if (report_missmatch)
+ if (report_missmatch) {
+ char buf[200];
fprintf(stderr, Name ": %s has wrong uuid.\n",
devname);
+ fprintf(stderr, " want %s\n",
__fname_from_uuid(ident->uuid, 0, buf, ':'));
+ fprintf(stderr, " have %s\n",
__fname_from_uuid(content->uuid, 0, buf, ':'));
+ fprintf(stderr, " metadata=%s\n",
tst->ss->name);
+ }
goto loop;
}
if (ident->name[0] && (!update || strcmp(update, "name")!= 0) &&
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101118122847.1530d...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm
> On Thu, 18 Nov 2010 11:11:49 +1100 wrote: > > > On Wed, 17 Nov 2010 17:36:23 -0500 Mike Viau wrote: > > > > > On Wed, 17 Nov 2010 14:15:14 +1100 > > > > > > This looks wrong. mdadm should be looking for the container as listed in > > > mdadm.conf and it should find a matching uuid on sda and sdb, but it > > > doesn't. > > > > > > Can you: > > > > > > mdadm -E /dev/sda /dev/sdb ; cat /etc/mdadm/mdadm.conf > > > > > > so I can compare the uuids? > > > > > > > Sure. > > > > # definitions of existing MD arrays ( So you don't have to scroll down :P ) > > > > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > > > > ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > > member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > > > >UUID : 084b969a:0808f5b8:6c784fb7:62659383 > > [OneTB-RAID1-PV]: > >UUID : ae4a1598:72267ed7:3b34867b:9c56497a > > > Yes, the uuids are definitely all correct. > This really should work. I just tested a similar config and it worked > exactly as exported. > Weird. > > Whatever version of mdadm are you running??? > Can you try getting the latest (3.1.4) from > http://www.kernel.org/pub/linux/utils/raid/mdadm/ I am running the same version, from a Debian Squeeze package which I presume is the same. mdadm -V mdadm - v3.1.4 - 31st August 2010 > > and see how that works. > Just > make > ./mdadm -Asvv Regardless, I did recompile (attached is the make output -- no errors) and got similar mdadm output: ./mdadm -Asvv mdadm: looking for devices for further assembly mdadm: no RAID superblock on /dev/md126p1 mdadm: /dev/md126p1 has wrong uuid. mdadm: no RAID superblock on /dev/md/OneTB-RAID1-PV mdadm: /dev/md/OneTB-RAID1-PV has wrong uuid. mdadm: no RAID superblock on /dev/dm-3 mdadm: /dev/dm-3 has wrong uuid. mdadm: no RAID superblock on /dev/dm-2 mdadm: /dev/dm-2 has wrong uuid. mdadm: no RAID superblock on /dev/dm-1 mdadm: /dev/dm-1 has wrong uuid. mdadm: no RAID superblock on /dev/dm-0 mdadm: /dev/dm-0 has wrong uuid. mdadm: no RAID superblock on /dev/loop0 mdadm: /dev/loop0 has wrong uuid. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm: /dev/sdc7 has wrong uuid. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm: /dev/sdc6 has wrong uuid. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm: /dev/sdc5 has wrong uuid. mdadm: no RAID superblock on /dev/sdc2 mdadm: /dev/sdc2 has wrong uuid. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm: /dev/sdc1 has wrong uuid. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm: /dev/sdc has wrong uuid. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm: /dev/sdb has wrong uuid. mdadm: cannot open device /dev/sda: Device or resource busy mdadm: /dev/sda has wrong uuid. mdadm: looking for devices for /dev/md/OneTB-RAID1-PV mdadm: no recogniseable superblock on /dev/md126p1 mdadm/dev/md126p1 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/md/OneTB-RAID1-PV mdadm/dev/md/OneTB-RAID1-PV is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-3 mdadm/dev/dm-3 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-2 mdadm/dev/dm-2 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-1 mdadm/dev/dm-1 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-0 mdadm/dev/dm-0 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/loop0 mdadm/dev/loop0 is not a container, and one is required. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm/dev/sdc7 is not a container, and one is required. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm/dev/sdc6 is not a container, and one is required. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm/dev/sdc5 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/sdc2 mdadm/dev/sdc2 is not a container, and one is required. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm/dev/sdc1 is not a container, and one is required. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm/dev/sdc is not a container, and one is required. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm/dev/sdb is not a container, and one is required. mdadm: cannot open device /dev/sda: Device or resource busy mdadm/dev/sda is not a container, and one is required. So what could this mean??? -M make gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\" -DMDMON_DIR=\"/dev/.mdadm\" -DUSE_PTHREADS -c -o mdadm.o mdadm.c gcc -Wall -Werror -Wstrict-prototypes -Wext
Re: How to recreate a dmraid RAID array with mdadm
On Wed, 17 Nov 2010 17:36:23 -0500 Mike Viau wrote: > > > On Wed, 17 Nov 2010 14:15:14 +1100 wrote: > > > > This looks wrong. mdadm should be looking for the container as listed in > > mdadm.conf and it should find a matching uuid on sda and sdb, but it > > doesn't. > > > > Can you: > > > > mdadm -E /dev/sda /dev/sdb ; cat /etc/mdadm/mdadm.conf > > > > so I can compare the uuids? > > > > Sure. > > # definitions of existing MD arrays ( So you don't have to scroll down :P ) > > > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > > ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > UUID : 084b969a:0808f5b8:6c784fb7:62659383 > [OneTB-RAID1-PV]: > UUID : ae4a1598:72267ed7:3b34867b:9c56497a > # definitions of existing MD arrays > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a Yes, the uuids are definitely all correct. This really should work. I just tested a similar config and it worked exactly as exported. Weird. Whatever version of mdadm are you running??? Can you try getting the latest (3.1.4) from http://www.kernel.org/pub/linux/utils/raid/mdadm/ and see how that works. Just make ./mdadm -Asvv NeilBrown -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010111849.7b500...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm
> On Wed, 17 Nov 2010 14:15:14 +1100 wrote: > > This looks wrong. mdadm should be looking for the container as listed in > mdadm.conf and it should find a matching uuid on sda and sdb, but it doesn't. > > Can you: > > mdadm -E /dev/sda /dev/sdb ; cat /etc/mdadm/mdadm.conf > > so I can compare the uuids? > Sure. # definitions of existing MD arrays ( So you don't have to scroll down :P ) ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a mdadm -E /dev/sda /dev/sdb /dev/sda: Magic : Intel Raid ISM Cfg Sig. Version : 1.1.00 Orig Family : 601eee02 Family : 601eee02 Generation : 1187 UUID : 084b969a:0808f5b8:6c784fb7:62659383 Checksum : 2f91ce06 correct MPB Sectors : 1 Disks : 2 RAID Devices : 1 Disk00 Serial : STF604MH0J34LB State : active Id : 0002 Usable Size : 1953520654 (931.51 GiB 1000.20 GB) [OneTB-RAID1-PV]: UUID : ae4a1598:72267ed7:3b34867b:9c56497a RAID Level : 1 Members : 2 Slots : [UU] This Slot : 0 Array Size : 1953519616 (931.51 GiB 1000.20 GB) Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB) Sector Offset : 0 Num Stripes : 7630936 Chunk Size : 64 KiB Reserved : 0 Migrate State : idle Map State : normal Dirty State : clean Disk01 Serial : STF604MH0PN2YB State : active Id : 0003 Usable Size : 1953520654 (931.51 GiB 1000.20 GB) /dev/sdb: Magic : Intel Raid ISM Cfg Sig. Version : 1.1.00 Orig Family : 601eee02 Family : 601eee02 Generation : 1187 UUID : 084b969a:0808f5b8:6c784fb7:62659383 Checksum : 2f91ce06 correct MPB Sectors : 1 Disks : 2 RAID Devices : 1 Disk01 Serial : STF604MH0PN2YB State : active Id : 0003 Usable Size : 1953520654 (931.51 GiB 1000.20 GB) [OneTB-RAID1-PV]: UUID : ae4a1598:72267ed7:3b34867b:9c56497a RAID Level : 1 Members : 2 Slots : [UU] This Slot : 1 Array Size : 1953519616 (931.51 GiB 1000.20 GB) Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB) Sector Offset : 0 Num Stripes : 7630936 Chunk Size : 64 KiB Reserved : 0 Migrate State : idle Map State : normal Dirty State : clean Disk00 Serial : STF604MH0J34LB State : active Id : 0002 Usable Size : 1953520654 (931.51 GiB 1000.20 GB) -- cat /etc/mdadm/mdadm.conf # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a # This file was auto-generated on Fri, 05 Nov 2010 16:29:48 -0400 # by mkconf 3.1.4-1+8efb9d1 -M -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w18a88e7d84ce0213b44f26ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
On Tue, 16 Nov 2010 21:44:10 -0500 Mike Viau wrote: > > > On Wed, 17 Nov 2010 12:26:47 +1100 wrote: > >> > >>> On Mon, 15 Nov 2010 16:21:22 +1100 wrote: > On Sun, 14 Nov 2010 01:50:42 -0500 Mike wrote: > > How does one fix the problem of not having the array not starting at > boot? > > >>> > >>> To be able to answer that one would need to know exactly what is in the > >>> initramfs. And unfortunately all distros are different and I'm not > >>> particularly familiar with Ubuntu. > >>> > >>> Maybe if you > >>> mkdir /tmp/initrd > >>> cd /tmp/initrd > >>> zcat /boot/initrd.img-2.6.32-5-amd64 | cpio -idv > >>> > >>> and then have a look around and particularly report etc/mdadm/mdadm.conf > >>> and anything else that might be interesting. > >>> > >>> If the mdadm.conf in the initrd is the same as in /etc/mdadm, then it > >>> *should* work. > >>> > >> > >> Thanks again Neil. I got a chance to examine my systems initramfs to > >> discover two differences in the local copy of mdadm.conf and the > >> initramfs's copy. > >> > >> The initramfs's copy contains: > >> > >> DEVICE partitions > >> HOMEHOST > >> ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > >> ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > >> member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a > >> > >> So both ARRAY lines got copied over to the initramfs's copy of mdadm.conf, > >> but > >> > >> CREATE owner=root group=disk mode=0660 auto=yes > >> > >> and > >> > >> MAILADDR root > >> > >> were not carried over on the update-initramfs command. > >> > >> > >> To your clearly better understanding of all this, does the CREATE stanza > >> NEED to be present in the initramfs's copy of mdadm.conf in order for the > >> array to be created on boot? If so, how can one accomplish this, so that > >> the line is added whenever a new initramfs is created for the kernel? > > > > No, those differences couldn't explain it not working. > > > > I would really expect that mdadm.conf file to successfully assemble the > > RAID1. > > > > As you have the same in /etc/mdadm/mdadm.conf you could see what is > > happening > > by: > > > > mdadm -Ss > > > > to stop all md arrays, then > > > > mdadm -Asvv > > > > to auto-start everything in mdadm.conf and be verbose about that is > > happening. > > > > If that fails to start the raid1, then the messages it produces will be > > helpful in understanding why. > > If it succeeds, then there must be something wrong with the initrd... > > Maybe '/sbin/mdmon' is missing... Or maybe it doesn't run > > mdadm -As > > (or equivalently: mdadm --assemble --scan) > > but doesn't something else. To determine what you would need to search for > > 'mdadm' in all the scripts in the initrd and see what turns up. > > > > Using mdadm -Ss stops the array: > > mdadm: stopped /dev/md127 > > > Where /dev/md127 is the imsm0 device and not the OneTB-RAID1-PV device. > > > Then executing mdadm -Asvv shows: > > mdadm: looking for devices for further assembly > mdadm: no RAID superblock on /dev/dm-3 > mdadm: /dev/dm-3 has wrong uuid. > mdadm: no RAID superblock on /dev/dm-2 > mdadm: /dev/dm-2 has wrong uuid. > mdadm: no RAID superblock on /dev/dm-1 > mdadm: /dev/dm-1 has wrong uuid. > mdadm: no RAID superblock on /dev/dm-0 > mdadm: /dev/dm-0 has wrong uuid. > mdadm: no RAID superblock on /dev/loop0 > mdadm: /dev/loop0 has wrong uuid. > mdadm: cannot open device /dev/sdc7: Device or resource busy > mdadm: /dev/sdc7 has wrong uuid. > mdadm: cannot open device /dev/sdc6: Device or resource busy > mdadm: /dev/sdc6 has wrong uuid. > mdadm: cannot open device /dev/sdc5: Device or resource busy > mdadm: /dev/sdc5 has wrong uuid. > mdadm: no RAID superblock on /dev/sdc2 > mdadm: /dev/sdc2 has wrong uuid. > mdadm: cannot open device /dev/sdc1: Device or resource busy > mdadm: /dev/sdc1 has wrong uuid. > mdadm: cannot open device /dev/sdc: Device or resource busy > mdadm: /dev/sdc has wrong uuid. > mdadm: cannot open device /dev/sdb: Device or resource busy > mdadm: /dev/sdb has wrong uuid. > mdadm: cannot open device /dev/sda: Device or resource busy > mdadm: /dev/sda has wrong uuid. This looks wrong. mdadm should be looking for the container as listed in mdadm.conf and it should find a matching uuid on sda and sdb, but it doesn't. Can you: mdadm -E /dev/sda /dev/sdb ; cat /etc/mdadm/mdadm.conf so I can compare the uuids? Thanks, NeilBrown > mdadm: looking for devices for /dev/md/OneTB-RAID1-PV > mdadm: no recogniseable superblock on /dev/dm-3 > mdadm/dev/dm-3 is not a container, and one is required. > mdadm: no recogniseable superblock on /dev/dm-2 > mdadm/dev/dm-2 is not a container, and one is required. > mdadm: no recogniseable superblock on /dev/dm-1 > mdadm/dev/dm-1 is not a container, and one is required. > mdadm: no recogniseable superblock on /dev/dm-0 > mdadm/dev/dm-0 is not a container, and one is required. > mdadm: no recogniseable superblock on /dev/loop0 >
RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
> On Wed, 17 Nov 2010 12:26:47 +1100 wrote: >> >>> On Mon, 15 Nov 2010 16:21:22 +1100 wrote: On Sun, 14 Nov 2010 01:50:42 -0500 Mike wrote: How does one fix the problem of not having the array not starting at boot? >>> >>> To be able to answer that one would need to know exactly what is in the >>> initramfs. And unfortunately all distros are different and I'm not >>> particularly familiar with Ubuntu. >>> >>> Maybe if you >>> mkdir /tmp/initrd >>> cd /tmp/initrd >>> zcat /boot/initrd.img-2.6.32-5-amd64 | cpio -idv >>> >>> and then have a look around and particularly report etc/mdadm/mdadm.conf >>> and anything else that might be interesting. >>> >>> If the mdadm.conf in the initrd is the same as in /etc/mdadm, then it >>> *should* work. >>> >> >> Thanks again Neil. I got a chance to examine my systems initramfs to >> discover two differences in the local copy of mdadm.conf and the initramfs's >> copy. >> >> The initramfs's copy contains: >> >> DEVICE partitions >> HOMEHOST >> ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 >> ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 >> member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a >> >> So both ARRAY lines got copied over to the initramfs's copy of mdadm.conf, >> but >> >> CREATE owner=root group=disk mode=0660 auto=yes >> >> and >> >> MAILADDR root >> >> were not carried over on the update-initramfs command. >> >> >> To your clearly better understanding of all this, does the CREATE stanza >> NEED to be present in the initramfs's copy of mdadm.conf in order for the >> array to be created on boot? If so, how can one accomplish this, so that the >> line is added whenever a new initramfs is created for the kernel? > > No, those differences couldn't explain it not working. > > I would really expect that mdadm.conf file to successfully assemble the > RAID1. > > As you have the same in /etc/mdadm/mdadm.conf you could see what is happening > by: > > mdadm -Ss > > to stop all md arrays, then > > mdadm -Asvv > > to auto-start everything in mdadm.conf and be verbose about that is happening. > > If that fails to start the raid1, then the messages it produces will be > helpful in understanding why. > If it succeeds, then there must be something wrong with the initrd... > Maybe '/sbin/mdmon' is missing... Or maybe it doesn't run > mdadm -As > (or equivalently: mdadm --assemble --scan) > but doesn't something else. To determine what you would need to search for > 'mdadm' in all the scripts in the initrd and see what turns up. > Using mdadm -Ss stops the array: mdadm: stopped /dev/md127 Where /dev/md127 is the imsm0 device and not the OneTB-RAID1-PV device. Then executing mdadm -Asvv shows: mdadm: looking for devices for further assembly mdadm: no RAID superblock on /dev/dm-3 mdadm: /dev/dm-3 has wrong uuid. mdadm: no RAID superblock on /dev/dm-2 mdadm: /dev/dm-2 has wrong uuid. mdadm: no RAID superblock on /dev/dm-1 mdadm: /dev/dm-1 has wrong uuid. mdadm: no RAID superblock on /dev/dm-0 mdadm: /dev/dm-0 has wrong uuid. mdadm: no RAID superblock on /dev/loop0 mdadm: /dev/loop0 has wrong uuid. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm: /dev/sdc7 has wrong uuid. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm: /dev/sdc6 has wrong uuid. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm: /dev/sdc5 has wrong uuid. mdadm: no RAID superblock on /dev/sdc2 mdadm: /dev/sdc2 has wrong uuid. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm: /dev/sdc1 has wrong uuid. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm: /dev/sdc has wrong uuid. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm: /dev/sdb has wrong uuid. mdadm: cannot open device /dev/sda: Device or resource busy mdadm: /dev/sda has wrong uuid. mdadm: looking for devices for /dev/md/OneTB-RAID1-PV mdadm: no recogniseable superblock on /dev/dm-3 mdadm/dev/dm-3 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-2 mdadm/dev/dm-2 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-1 mdadm/dev/dm-1 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-0 mdadm/dev/dm-0 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/loop0 mdadm/dev/loop0 is not a container, and one is required. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm/dev/sdc7 is not a container, and one is required. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm/dev/sdc6 is not a container, and one is required. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm/dev/sdc5 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/sdc2 mdadm/dev/sdc2 is not a container, and one is required. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm/dev/sdc1 is not a cont
RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
> On Wed, 17 Nov 2010 12:53:37 +1100 wrote: > On Wed, 17 Nov 2010 01:39:39 + > John Robinson wrote: > > > On 17/11/2010 01:26, Neil Brown wrote: > > > On Tue, 16 Nov 2010 20:02:17 -0500 > > > Mike Viau wrote: > > [...] > > >> DEVICE partitions > > >> HOMEHOST > > >> ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > > >> ARRAY /dev/md/OneTB-RAID1-PV > > >> container=084b969a:0808f5b8:6c784fb7:62659383 member=0 > > >> UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > [...] > > > I would really expect that mdadm.conf file to successfully assemble the > > > RAID1. > > > > The only thing that strikes me is that "DEVICE partitions" line - surely > > imsm containers don't live in partitions? > > No, they don't. > > But "DEVICE partitions" actually means "any devices listed > in /proc/partitions", and that includes whole devices. > :-( > I noticed both /dev/sda and /dev/sdb (the drives which make up the raid1 array) do not appear to recognized as having a valid container when one is required. The output of mdadm -Asvv shows: mdadm -Asvv mdadm: looking for devices for further assembly mdadm: no RAID superblock on /dev/dm-3 mdadm: /dev/dm-3 has wrong uuid. mdadm: no RAID superblock on /dev/dm-2 mdadm: /dev/dm-2 has wrong uuid. mdadm: no RAID superblock on /dev/dm-1 mdadm: /dev/dm-1 has wrong uuid. mdadm: no RAID superblock on /dev/dm-0 mdadm: /dev/dm-0 has wrong uuid. mdadm: no RAID superblock on /dev/loop0 mdadm: /dev/loop0 has wrong uuid. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm: /dev/sdc7 has wrong uuid. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm: /dev/sdc6 has wrong uuid. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm: /dev/sdc5 has wrong uuid. mdadm: no RAID superblock on /dev/sdc2 mdadm: /dev/sdc2 has wrong uuid. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm: /dev/sdc1 has wrong uuid. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm: /dev/sdc has wrong uuid. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm: /dev/sdb has wrong uuid. mdadm: cannot open device /dev/sda: Device or resource busy mdadm: /dev/sda has wrong uuid. mdadm: looking for devices for /dev/md/OneTB-RAID1-PV mdadm: no recogniseable superblock on /dev/dm-3 mdadm/dev/dm-3 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-2 mdadm/dev/dm-2 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-1 mdadm/dev/dm-1 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/dm-0 mdadm/dev/dm-0 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/loop0 mdadm/dev/loop0 is not a container, and one is required. mdadm: cannot open device /dev/sdc7: Device or resource busy mdadm/dev/sdc7 is not a container, and one is required. mdadm: cannot open device /dev/sdc6: Device or resource busy mdadm/dev/sdc6 is not a container, and one is required. mdadm: cannot open device /dev/sdc5: Device or resource busy mdadm/dev/sdc5 is not a container, and one is required. mdadm: no recogniseable superblock on /dev/sdc2 mdadm/dev/sdc2 is not a container, and one is required. mdadm: cannot open device /dev/sdc1: Device or resource busy mdadm/dev/sdc1 is not a container, and one is required. mdadm: cannot open device /dev/sdc: Device or resource busy mdadm/dev/sdc is not a container, and one is required. mdadm: cannot open device /dev/sdb: Device or resource busy mdadm/dev/sdb is not a container, and one is required. mdadm: cannot open device /dev/sda: Device or resource busy mdadm/dev/sda is not a container, and one is required. and cat /proc/partitions shows: major minor #blocks name 8 0 976762584 sda 8 16 976762584 sdb 8 32 78125000 sdc 8 33 487424 sdc1 8 34 1 sdc2 8 37 20995072 sdc5 8 38 7811072 sdc6 8 39 48826368 sdc7 7 0 4388218 loop0 254 0 10485760 dm-0 254 1 10485760 dm-1 254 2 10485760 dm-2 254 3 17367040 dm-3 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w57593947743ef205225d2aef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
On 17/11/2010 01:26, Neil Brown wrote: On Tue, 16 Nov 2010 20:02:17 -0500 Mike Viau wrote: [...] DEVICE partitions HOMEHOST ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a [...] I would really expect that mdadm.conf file to successfully assemble the RAID1. The only thing that strikes me is that "DEVICE partitions" line - surely imsm containers don't live in partitions? Cheers, John. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce3325b.7050...@anonymous.org.uk
Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
On Wed, 17 Nov 2010 01:39:39 + John Robinson wrote: > On 17/11/2010 01:26, Neil Brown wrote: > > On Tue, 16 Nov 2010 20:02:17 -0500 > > Mike Viau wrote: > [...] > >> DEVICE partitions > >> HOMEHOST > >> ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > >> ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > >> member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a > [...] > > I would really expect that mdadm.conf file to successfully assemble the > > RAID1. > > The only thing that strikes me is that "DEVICE partitions" line - surely > imsm containers don't live in partitions? No, they don't. But "DEVICE partitions" actually means "any devices listed in /proc/partitions", and that includes whole devices. :-( NeilBrown > > Cheers, > > John. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117125337.2ca80...@notabene.brown
Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
On Tue, 16 Nov 2010 20:02:17 -0500 Mike Viau wrote: > > > On Mon, 15 Nov 2010 16:21:22 +1100 wrote: > > > On Sun, 14 Nov 2010 01:50:42 -0500 Mike wrote: > > > > > > How does one fix the problem of not having the array not starting at boot? > > > > > > > To be able to answer that one would need to know exactly what is in the > > initramfs. And unfortunately all distros are different and I'm not > > particularly familiar with Ubuntu. > > > > Maybe if you > > mkdir /tmp/initrd > > cd /tmp/initrd > > zcat /boot/initrd.img-2.6.32-5-amd64 | cpio -idv > > > > and then have a look around and particularly report etc/mdadm/mdadm.conf > > and anything else that might be interesting. > > > > If the mdadm.conf in the initrd is the same as in /etc/mdadm, then it > > *should* work. > > > > Thanks again Neil. I got a chance to examine my systems initramfs to discover > two differences in the local copy of mdadm.conf and the initramfs's copy. > > The initramfs's copy contains: > > DEVICE partitions > HOMEHOST > ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 > ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 > member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a > > So both ARRAY lines got copied over to the initramfs's copy of mdadm.conf, but > > CREATE owner=root group=disk mode=0660 auto=yes > > and > > MAILADDR root > > were not carried over on the update-initramfs command. > > > To your clearly better understanding of all this, does the CREATE stanza NEED > to be present in the initramfs's copy of mdadm.conf in order for the array to > be created on boot? If so, how can one accomplish this, so that the line is > added whenever a new initramfs is created for the kernel? No, those differences couldn't explain it not working. I would really expect that mdadm.conf file to successfully assemble the RAID1. As you have the same in /etc/mdadm/mdadm.conf you could see what is happening by: mdadm -Ss to stop all md arrays, then mdadm -Asvv to auto-start everything in mdadm.conf and be verbose about that is happening. If that fails to start the raid1, then the messages it produces will be helpful in understanding why. If it succeeds, then there must be something wrong with the initrd... Maybe '/sbin/mdmon' is missing... Or maybe it doesn't run mdadm -As (or equivalently: mdadm --assemble --scan) but doesn't something else. To determine what you would need to search for 'mdadm' in all the scripts in the initrd and see what turns up. NeilBrown > > > My diff findings between the local copy of mdadm.conf and the initramfs's > copy pasted at: > http://debian.pastebin.com/5VNnd9g1 > > > Thanks for your help. > > > -M > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117122647.48c7b...@notabene.brown
RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
> On Mon, 15 Nov 2010 16:21:22 +1100 wrote: > > On Sun, 14 Nov 2010 01:50:42 -0500 Mike wrote: > > > > How does one fix the problem of not having the array not starting at boot? > > > > To be able to answer that one would need to know exactly what is in the > initramfs. And unfortunately all distros are different and I'm not > particularly familiar with Ubuntu. > > Maybe if you > mkdir /tmp/initrd > cd /tmp/initrd > zcat /boot/initrd.img-2.6.32-5-amd64 | cpio -idv > > and then have a look around and particularly report etc/mdadm/mdadm.conf > and anything else that might be interesting. > > If the mdadm.conf in the initrd is the same as in /etc/mdadm, then it > *should* work. > Thanks again Neil. I got a chance to examine my systems initramfs to discover two differences in the local copy of mdadm.conf and the initramfs's copy. The initramfs's copy contains: DEVICE partitions HOMEHOST ARRAY metadata=imsm UUID=084b969a:0808f5b8:6c784fb7:62659383 ARRAY /dev/md/OneTB-RAID1-PV container=084b969a:0808f5b8:6c784fb7:62659383 member=0 UUID=ae4a1598:72267ed7:3b34867b:9c56497a So both ARRAY lines got copied over to the initramfs's copy of mdadm.conf, but CREATE owner=root group=disk mode=0660 auto=yes and MAILADDR root were not carried over on the update-initramfs command. To your clearly better understanding of all this, does the CREATE stanza NEED to be present in the initramfs's copy of mdadm.conf in order for the array to be created on boot? If so, how can one accomplish this, so that the line is added whenever a new initramfs is created for the kernel? My diff findings between the local copy of mdadm.conf and the initramfs's copy pasted at: http://debian.pastebin.com/5VNnd9g1 Thanks for your help. -M -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bay148-w211ae8bf243615980ce527ef...@phx.gbl
Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
On Sun, 14 Nov 2010 01:50:42 -0500 Mike Viau wrote: > Again, How does one fix the problem of not having the array not starting at > boot? > To be able to answer that one would need to know exactly what is in the initramfs. And unfortunately all distros are different and I'm not particularly familiar with Ubuntu. Maybe if you mkdir /tmp/initrd cd /tmp/initrd zcat /boot/initrd.img-2.6.32-5-amd64 | cpio -idv and then have a look around and particularly report etc/mdadm/mdadm.conf and anything else that might be interesting. If the mdadm.conf in the initrd is the same as in /etc/mdadm, then it *should* work. NeilBrown -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101115162122.4fef2...@notabene.brown
