Joe / et-al,
The '--assemble --update=uuid' appears to have done the trick. It is
weird because the uuid in the config file matched the uuid of the raid
volume shown with 'mdadm -D /dev/md3' and the uuid on each of the drives
shown with 'mdadm -E /dev/sdc1'
The '--update=summaries' did not work. Assigning a new random uuid
appears to have repaired whatever bit in the superblock was mucked up.
Strange...
Joe, thanks for your help. Find me at SC11, I'm buying you beers.
--Jeff
On 8/7/11 10:04 PM, Joe Landman wrote:
Maybe '--update=uuid' ??
It looks like it correctly finds /dev/sd[c-z]1 as elements of /dev/md3
Which mdadm are you using?
mdadm -V
and which kernel?
Try the UUID update, and let us know if it helps. Also if your mdadm
is old (2.6.x), try updating to 3.1.x.
FWIW: we've found problems in the past with Centos 5.4 to 5.5 kernels
with MD arrays. Often times our only real solution would be to update
the full OS on the boot drives. This is for distro specific kernels.
For our kernels, we don't run into this issue.
--
------------------------------
Jeff Johnson
Manager
Aeon Computing
jeff.johnson "at" aeoncomputing.com
www.aeoncomputing.com
t: 858-412-3810 x101 f: 858-412-3845
4905 Morena Boulevard, Suite 1313 - San Diego, CA 92117
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
