Comment 21 for bug 452350

I've been bitten too. I have a software RAID 10, /dev/md0, which is made up of /dev/sd[a-d]2. /dev/md0 is the only "physical" volume in a volume group. Looking at the first two sectors of /dev/sd[a-d]2, there are indeed volume group manager labels, but this is as I would expect: they're holding data for the first two sectors of /dev/md0 — the md driver's overhead loses a little space at the end of the volume, but none at the beginning. If I point pvck at /dev/sd[a-d]2, it correctly ignores them, as they're part of an md device. I'm not about to zap these labels, as I think they're valid. Could the problem be that update-grub (and, incidentally, the boot process, where one can see the same error message flitting by) is not as smart as mdadm, and is not ignoring partitions that are claimed by an md device?