1 |
On Sunday 31 May 2015 13:06:58 Mick wrote: |
2 |
> On Sunday 31 May 2015 10:01:43 Peter Humphrey wrote: |
3 |
> > On Friday 29 May 2015 01:10:52 I wrote: |
4 |
> > > OK, so this is what I have at present. I haven't booted with it yet to |
5 |
> > > test it - I'll do that in the morning: |
6 |
> > > |
7 |
> > > DEVICE /dev/sd[abcde][123456789] |
8 |
> > > ARRAY /dev/md1 UUID=ea156c7f:183ca28e:c44c77eb:7ee19756 |
9 |
> > > ARRAY /dev/md5 UUID=e7640378:966a5b3a:c44c77eb:7ee19756 |
10 |
> > > ARRAY /dev/md7 UUID=c2d056c4:9118021f:ad73c633:b38fa97c |
11 |
> > |
12 |
> > Specifying the UUIDs hasn't helped. I still get failure to start /dev/md7 |
13 |
> > during boot as often as not. |
14 |
> |
15 |
> Did you try my suggestion to (also) specify the metadata type to see if it |
16 |
> makes a difference? |
17 |
|
18 |
Ah, no, I missed that. I'll try it and see how it goes. |
19 |
|
20 |
> Something else to check: |
21 |
> |
22 |
> Make sure that the /etc/fstab name for the RAID device and your |
23 |
> /etc/mdadm.conf use the same name. |
24 |
|
25 |
Yes, they're the same - but fstab isn't consulted until long after the VGs are |
26 |
started, is it? |
27 |
|
28 |
> If you have changed the partitions on this RAID, or recreated it, make sure |
29 |
> to run 'mdadm --zero-superblock', before you delete the partition from the |
30 |
> partition table, or you could recover it when you recreate a partition if |
31 |
> not zeroed. |
32 |
|
33 |
Nope, haven't changed anything since creation. |
34 |
|
35 |
> Have a look at smartctl output to see if there is something wrong with any |
36 |
> of the md7 disks. |
37 |
|
38 |
I was suspicious of the spinning disks I've just replaced with SSDs, because |
39 |
they were showing a few errors and not a lot of remaining life. Smartctl |
40 |
doesn't recognise the SSDs so I don't know how useful its output is, but it's |
41 |
not reporting anything anyway. |
42 |
|
43 |
-- |
44 |
Rgds |
45 |
Peter |