Comment 10 for bug 567345

I cannot reproduce your GRUB problems. With my fixed parted and busybox packages applied to the running installer, I was able to do a test installation as follows:

  {/dev/vda1, /dev/vdb1, /dev/vdc1 (spare)} -> /dev/md0 (unused)
  {/dev/vda2, /dev/vdb2, /dev/vdc2 (spare)} -> /dev/md1 (ext4, /)

(The odd device names are because I was using virtio block devices in KVM. This shouldn't affect the outcome here; in fact if anything virtio usually exposes additional problems.)

GRUB was correctly installed to /dev/vda and /dev/vdb (though it might have been nice if it had been installed to /dev/vdc too; I'm not sure what the correct behaviour with spares is), and the resulting system booted with no assistance. Incidentally, the installer did indeed ask me to confirm whether I wanted to install GRUB to the MBR, and if I'd said no to that I could have entered one or more target devices manually.

Your output in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/527401/comments/28 clearly indicates that GRUB Legacy was used, not GRUB 2. Why this should be the case, I don't know - we don't do this by default for RAID, and the syslog you posted in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/527401/comments/37 shows no evidence of this happening. Perhaps it was some odd side-effect of the parted bug, not that I can think how.

Regarding your fdisk comment in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/527401/comments/39, this is quite natural and expected because partman does not use partitioned RAID devices, but instead simply writes filesystems directly to /dev/md*. Thus, there's nothing for fdisk to read.

Could you please try a daily build once my two fixes so far have landed (which should be the case by Saturday's daily build) and see what's left? My instinct is that there was a fair amount of collateral damage from early errors and that this has created substantial confusion.