Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote:
> also sprach lrhorer <lrhorer@satx.rr.com> [2011.02.02.2047 +0100]:
>> ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0
>> UUID=431244d6:45d9635a:e88b3de5:92f30255
>
> What's metadata=01.2. I suggest you remove the 0, except for this
> one line:
I'll give it a shot, although it shouldn't matter. Note I didn't
create the line. Mdadm did. I suppose there could be a version
incompatibility between the two initrds, but there shouldn't be. Both
report the same version of mdadm. Besides, if it were a problem, why
do they assemble at all? How is it I can stop and then re-assemble the
arrays with no problems? (Not to mention, how is it it works under
2.6.32-5?)
>> ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90
>> UUID=4cde286c:0687556a:4d9996dd:dd23e701
I definitely know this won't matter, since md1 is not required once the
initrd is loaded. Md1 is the boot array, containing GRUB, the kernel,
and of course the initrd. It's not used once GRUB has done its work,
the kernel is live, and the RAM Disk is operational. Md2 is the
critical array, at this point, and its failure to mount is what is
causing the boot to fail.
>> > And what does /proc/mdstat contain at this point.
>>
>> Before I stop and re-start the arrays, all four show
>> inactive.
>
> Are they degraded?
Nope. 100% clean, both when inactive and when active. No drives
faulty or removed. The arrays and the file systems are both pristine.
Why md is assembling the arrays but not activating them is the
question.
> Also, judging from your dmesg output, you *do* have hardware
> problems.
Where? I'm not seeing anything related to md or anything which would
cause the arrays not to start.
> Also, what version of mdadm are you using? Which package?
Debian "Squeeze". Both the mdadm binary in the 2.6.32-5 and in
the /sbin/ directory of the root array report 3.1.2, which is the
version supported in the distro.
Reply to: