Re: [gentoo-user] Re: How does grub assemble a RAID1 for / ??

[Mark Knecht]

On Sun, Apr 4, 2010 at 3:47 PM, Kerin Millar <kerframil@×××××.com> wrote:
> On 04/04/2010 23:16, Mark Knecht wrote:
>>
>>    First, thanks for sticking with me on this. I really appreciate it.
>> Second, I apologize for the length of the reply but it's still not
>> working and I wanted to try and clearly show the steps I've taken.
>> Maybe you or someone else will see the step I'm missing.
>
> [snip]
>
>> I don't know what to try next.
>
> OK, I think I now understand what's happening here. I regret that I did not
> recall this earlier but only the original RAID superblock format (version
> 0.90.00) is supported for automatic assembly! I have two servers that are
> set up in a similar way as your box, and they both use this format. It's
> possible that the docs may be out of date but
> /usr/src/linux/Documentation/md.txt says:
>
> "When md is compiled into the kernel (not as module), partitions of type
> 0xfd are scanned and automatically assembled into RAID arrays. This
> autodetection may be suppressed with the kernel parameter
> "raid=noautodetect".  As of kernel 2.6.9, only drives with a type 0
> superblock can be autodetected and run at boot time."
>
> Also, look at this:
>
> http://www.mail-archive.com/linux-raid@×××××××××××.org/msg06215.html
>
> To quote Neil Brown:
>
> "v0.90 can be used with 'in kernel autodetect' (i.e. partition type 0xfd).
> v1 cannot (I consider this an improvement :-)"
>
> Well, I can't say I agree with him there.
>
> Anyway, it seems that you're using the 1.1 superblock format. So, what
> options does this leave you with?
>
> a) Backup the root filesystem, and re-create the array with the regular
>   superblock format. If necessary, coerce mdadm with -e 0 but it should
>   be a default.
>
> b) Rely on userspace tools to assemble the array. This means either
>   having the root filesystem off raid, or using an initrd/initramfs
>   image.
>
> I'd got for the first option as it keeps things simple and the benefits of
> the v1 format are nebulous in practical terms.
>
> Cheers,
>
> --Kerin
>
>
>

Hi,
   From my post this morning:

"No problem supplying it. I did the rebuild this morning but forced
metadata to Type 1.0. No change as you suggested there wouldn't be."

I guess I didn't post it there but what I meant by that was the following:

1) If you don't specify metadata then you get the newest - I think
that's currently ver. 1.2 or something.

2) I tried 1.0 this morning (shown below) which didn't fix it.

(commands used are below)

I will immediately try 0.90 as I have no problem with the limitations
at this time:

              0, 0.90
                     Use  the  original  0.90  format superblock.
This format limits arrays to 28 component
                     devices and limits component devices of levels 1
and greater to 2 terabytes.

I should hopefully know in an hour or two how this worked.

Thanks for the help!

Cheers,
Mark

keeper ~ # mdadm --create /dev/md0 --level=1 --raid-devices=2
/dev/sdb3 /dev/sdc3
mdadm: Note: this array has metadata at the start and
   may not be suitable as a boot device.  If you plan to
   store '/' or '/boot' on this device please ensure that
   your boot-loader understands md/v1.x metadata, or use
   --metadata=1.0
mdadm: Note: this array has metadata at the start and
   may not be suitable as a boot device.  If you plan to
   store '/' or '/boot' on this device please ensure that
   your boot-loader understands md/v1.x metadata, or use
   --metadata=1.0
Continue creating array? n
mdadm: create aborted.
keeper ~ #  mdadm --create /dev/md0 --level=1 --raid-devices=2
--metadata=1.0 /dev/sdb3 /dev/sdc3
mdadm: array /dev/md0 started.
keeper ~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdc3[1] sdb3[0]
     31463228 blocks super 1.0 [2/2] [UU]
     [>....................]  resync =  3.9% (1241664/31463228)
finish=5.2min speed=95512K/sec

unused devices: <none>
keeper ~ #