Here's phcoder's explanation of the problem:
16:08< phcoder> if you have< 64KiB between end of disk and end of partition
the metadata is exactly in the same place for either if the
whole disks are raided or only partitions. And no field which
allows to distinguish those
[...]
16:09< phcoder> thing is that mdraid format rounds it down to a 64K aligned
boundary
16:10< dkg0> 64KiB aligned to the parent disk, or to the partition itself?
16:10< phcoder> to whatever the host of the raid is. For your error to occur
it has to be both
16:10< dkg0> hm, i suppose if the partition itself starts evenly aligned with
a 64KiB boundary, it'd be the same thing.
It sounds like there might be some circumstances (e.g. a RAID0 set of
sda and sdb, creating md0, and a partition table on top of md0) where it
is legitimately difficult to decide the correct interpretation.
However, i think there might be a reasonable heuristic that can be used
in the case of RAID1 sets that would avoid the ambiguity (and the scary
messages/warnings to the user:
Select the smallest known block device that can completely enclose the
RAID member. The larger block device(s) should not be considered to be
exporting that RAID.
these heuristics would mean that RAID1 sets with 0.9x metadata on any
sort of disklabel would only have their member components show up once
during a scan, rather than treating them as a duplicate.
phcoder mentioned that the RAID code was undergoing something of an
overhaul. perhaps these heuristics could play into that update?
I'm not sure how to address it with RAID0 or RAID10, but if we could fix
the RAID1 case, that would be a big win for a lot of users.
Regards,
--dkg
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel
filterguess.diff