[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Squeeze assembles one RAID array, at boot but not the other



Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> On Mon, 07 Jan 2013 06:07:37 +0100, Sven Hartge wrote:
>> Hendrik Boom <hendrik@topoi.pooq.com> wrote:
 
>>> But it is not recognized at boot.  The dmesg output tells me all
>>> about finding the old RAID, but it doesn't even notice the new one,
>>> not even to complain about it.
>> 
>>> It seems the significant differences bwtween the two RAIDS are:
>> 
>>> One is new, and the other os old.  One is on a GPT-partitioned disk
>>> and the other uses the MBR partion table.  One is huge and the other
>>> is just large.
>> 
>>> Any ideas where to look?  Or how to work around the problem?
>> 
>> What type are those partitions for your RAID inside the GPT? They
>> should look like this (output from gdisk -l):
>> 
>> Number  Start (sector)    End (sector)  Size       Code  Name
>>    1            2048      5860533134   2.7 TiB     FD00  primary
>> 
>> Note the Code "FD00" which stands for "Linux RAID". 
>> 
>> I guess (using my magic crystal ball) that your type/code is 8300 and
>> thus the initrd/kernel won't assemble the RAID.

> Half right.  It's 0700.  The same as the code for my ext4 partition
> that is not part of the RAID.  As far as I remember, gparted didn't
> give me the choice of specifying it be the carrier for a RAID.  But
> did let me tell it that the other partition would be ext4.

This is why I kind of dislike gparted as frontend to libparted by now.
It is too limited or too strict in the ways of allowing you to do stuff.

I mostly use the tools from gnu-fdisk for my partitioning needs right
now.

> Can I change the partition type without losing contents?  (not that it
> would be a disaster if I did -- I can regenerate it all with rsync)
> Should I use gdisk instead of gparted?

You may change this at any time without losing any content.

>> Or you just need to "dpkg --reconfigure mdadm" to tell it to assemble
>> all arrays and not just the ones needed to boot.

> Presumably to regenerate the mdadm.conf file that other messages are
> telling me about?  The raid that isn't autoassembling isn't needed for
> boot; the one that is, is needed for boot (it contains / although not
> /boot).

Yes. As others said, new RAIDs are normally created with metadata 1.2,
which is only assembled by the initrd if the mdadm.conf (and
/etc/default/mdadm) tells it to do so.

You may also create a mdadm.conf by manually running
/usr/share/mdadm/mkconf as root, editing the results as needed, placing
it into /etc/mdadm.conf, update your initramfs and be done.

This should normally suffice to get your arrays up and running.

If not, you need to provide more information, log exempts, content of
/proc/mdstat, dmesg, etc.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


Reply to: