Bug#554500: grub-pc doesn't work with metadata 1.0 md device

[Peter Henn]

Felix thanks for your first implementation supporting metadata v1.x raid
disks. I tried it on my RAID5 with v1.0 superblock. But it needs some
bugfixes:

Looking into the kernel code, obviously v0.9 superblocks and v1.x
superblocks save some values in a different dimension unit:
v0.9 chunk_size in byte
v1.x chunk_size in sectors of 512 byte
v0.9 disk_size in blocks of 1 kbyte = 1024 byte
v1.x disk_size in sectors of 512 byte

Without any additional recalculation this two fixes gave me a first
chance to boot my system, using a boot partition on a LVM2 volume inside
that RAID5 of 3 disks inside a standard PC partition (you should move
the data part of the 1st partition by some additional sectors, because
the core.img needs more that the default reserved 31 sectors here).
But unfortunately the grub-probe claimed that it requires the raid5rec
module and booting works only with the first 2 disks assembled in my
system (I used the   grub-install --modules=ext2 /dev/md0   for this
first trail). Looking on the RAID superblock, especially the "Array
Slot" gave me the final hint:

> /sbin/mdadm -E /dev/sdc2
> /dev/sdc2:
>           Magic : a92b4efc
>         Version : 1.0
>     Feature Map : 0x0
>      Array UUID : 4e929199:313b3aee:c12d54f0:e74b3a0b
>            Name : rheinberg:raid5
>   Creation Time : Sat Oct 31 20:43:47 2009
>      Raid Level : raid5
>    Raid Devices : 3
> 
>  Avail Dev Size : 1937872480 (924.05 GiB 992.19 GB)
>      Array Size : 3875744768 (1848.10 GiB 1984.38 GB)
>   Used Dev Size : 1937872384 (924.05 GiB 992.19 GB)
>    Super Offset : 1937872736 sectors
>           State : clean
>     Device UUID : 064806c1:0fc61a78:b3df4fed:840743e4
> 
>     Update Time : Thu Dec 17 01:59:54 2009
>        Checksum : 654ad2e3 - correct
>          Events : 114
> 
>          Layout : left-symmetric
>      Chunk Size : 256K
> 
>     Array Slot : 3 (0, 1, failed, 2)
>    Array State : uuU 1 failed

The index in the Array Slot with dev_number=2 is marked as failed and
does not exists on my RAID. My disk uses a disk-ID with value 3, which
can obviously grub2 not use as its array->index, because it expects here
disk 0, 1 or 2. Using the given dev_role array, which is appended at the
end of the superblock v1.x, solved this issue just be using it as a
translation table.
So the correct part of maraid_linux.c should be something like:

>   array->total_devs = grub_le_to_cpu32 (sb_1x->raid_disks);
>   array->disk_size = grub_le_to_cpu64 (sb_1x->size);
>   array->chunk_size = grub_le_to_cpu32 (sb_1x->chunksize);
>   if (grub_le_to_cpu32(sb_1x->dev_number) < grub_le_to_cpu32(sb_1x->max_dev))
>     array->index = grub_le_to_cpu16 (sb_1x->dev_roles[ grub_le_to_cpu32(sb_1x->dev_number) ]);
>   else
>     array->index = 0xffff;  // disk will be later not used !
>   array->uuid_len = 16;

With all these changes I could boot my machine also with anyone of the 3
disks removed.

Additionally I attached a corrected patch for using meta data 1.0, which
should work with
- grub2_1.97+20091125-1
- grub2_1.97+20091130-1
- grub2_1.98~20091210-1
by just adding that file into the /debian/patches directory.

Note that I haven't tested it with md meta data version > 1.0, e.g. 1.1
or 1.2 and also not with other RAID levels!

Peter
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 908_raid_v1.x_support.diff
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20091217/9d29bdac/attachment.txt>