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

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



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.

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?

-- hendrik


> 
> 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).

> 
> Grüße,
> Sven.
> 
> -- 
> Sigmentation fault. Core dumped.



Reply to: