mdadm doesn't recognize partitions, the Linux kernel does. A software RAID array doesn't need to know or care what type of partitions the disk uses, because it just uses the block devices that the kernel provides for the partitions. I'm using mdadm arrays on GPT disks on several computers and they work fine.
The partition layout you described doesn't make sense:
/dev/sda
/dev/sda1 <- GPT type partition
/dev/sda1 <- exists within the GPT part, member of md127
/dev/sda2 <- exists within the GPT part, empty
/dev/sdb
/dev/sdb1 <- GPT type partition
/dev/sdb1 <- exists within the GPT part, member of md127
In particular, it looks like you're saying that sda2 is located within sda1. Partitions don't exist within other partitions, and GPT is a characteristic of the whole-disk device, not a partition. I think what you actually mean is:
/dev/sda <- GPT disk
/dev/sda1 <- member of md127
/dev/sda2 <- empty
/dev/sdb <- GPT disk
/dev/sdb1 <- member of md127
However, your blkid output says that /dev/sda1 currently contains an Ext4 filesystem, not a RAID superblock — it's not a member of md127. It's not clear how that filesystem got there, since you said that you were using it as a RAID component, but since your story is long and full of twists, I suspect there may have been points where things happened that you didn't realize had happened. My suggestion at this point is:
- Assemble the array in degraded mode using just
/dev/sdb1. Check that it contains your data; if not, check whether /dev/sda1 somehow contains an intact filesystem with your data, otherwise I hope you have a backup.
- Make a backup of all your data, if you don't have one already.
- Completely wipe
/dev/sda: dd if=/dev/zero of=/dev/sda bs=1M. Then use gdisk to recreate the partition(s).
- Create a new degraded array using only a partition on
sda. Make a filesystem in it, and copy your data into it.
- Disassemble the array that's using
sdb1, and completely wipe /dev/sdb: dd if=/dev/zero of=/dev/sdb bs=1M. Then use gdisk to recreate the partition.
- Add
/dev/sdb1 to the new array and let it sync.
As for installing GRUB, it depends on whether your machine supports EFI (and whether you're using it for booting). If you're using EFI, you need to make an EFI system partition somewhere; it should be roughly 100MB, formatted FAT32. Then you'd install the EFI version of GRUB. I won't go into too much detail on this; EFI booting is a topic for a separate question.
If you're not using EFI to boot, you need to make a "BIOS Boot" partition somewhere on the disk that you'll be installing GRUB on. (This is partition type code ef02 in gdisk.) The partition can be tiny; 1MB is plenty. GRUB will use this to store the boot code that it would have written to sectors 1 through 62 on an MBR disk. (On an MBR disk, those sectors are typically unallocated since the first partition typically begins at sector 63, but on a GPT disk, the partition table is located in that area.) GRUB should automatically notice that the disk you're installing it to contains a BIOS Boot partition, and put its boot code there instead of in sectors 1-62.
Solution is to use a bios_grub partition, which is not the same as the /boot partition.
By default the bios_grub partition is 1MiB, and it must be flagged bios_grub. Mine is the first partition on my disk. If your partition 2 is actually /boot as parted suggests, that would not be correct and you should make another 1MiB partition.
With GPT and GRUB2 the minimum filesystem has three partitions: bios_grub, root, swap. (not perfectly sure swap is required)
Why does grub fail to boot after simply running "grub-install"?
Unknown... You'd think it wouldn't modify anything if it says clearly it cannot embed so it can't work.
Why does it say "file not found"?
/vmlinuz is a symlink that uses the boot partition, and the boot partition is corrupt. The bios_grub code was written on top of its ext3 structure. This probably meant that /boot was not mounted, and the grub files seen there were actually on the root system, which didn't contain the kernel.
Why doesn't grub want to install without this setting I set with parted
A GPT partition table has no space for a bootloader, unlike MBR. So a specific partition must be created to hold the boot code. Before running "grub-install", specify this partition with the command:
parted /dev/sda set 1 bios_grub on
I thought all I needed was a separate /boot. How does the Ubuntu CD installer install it without the bios_grub setting?
This requirement seems to be all that is needed for the Ubuntu installer, but it creates an unstandard system which is broken easily.
When GRUB says "This GPT partition label has no BIOS Boot Partition", it means the bios_grub partition, not /boot.
Best Answer
GPT has partition type codes just like MBR; the difference is that they're 128-bit GUIDs instead of 8-bit integers. But they serve the same purpose.
GNU Parted hides them from you, though. Those flags you see, like "boot" and "raid", are specific to Parted. When you set the "boot" flag, it actually sets the partition's type code to the GUID for an EFI System partition. When you set the "raid" flag, it sets the partition's type code to a different GUID that indicates a Linux software RAID component device. That's why those flags (and a number of others that control the partition type) are mutually exclusive.
I don't really like Parted, both for its strange way of exposing GPT type codes and because it lacks some conveniences compared to fdisk (like being able to type "+10G" to specify a partition's end relative to its start). For GPT partitioning, I use "gdisk", which is a lot like the conventional fdisk, but for GPT. In gdisk, you can set a partiton's type either by specifying the GUID itself, or by choosing from a table of shorthand numbers that's similar to the one you get by typing 'L' in fdisk.