Ubuntu – How to manually install boot loader

The GUID Partition Table (GPT) is a way of partitioning disks that's more flexible than the older Master Boot Record (MBR) system. GPT works on bigger disks than MBR (which has a 2 TiB limit, assuming a standard 512-byte sector size) and it has some other minor advantages. When GRUB 2 installs to a GPT disk on a BIOS-based computer, it likes to have a BIOS Boot Partition in place, and this is what Ubuntu's installer means by the "bios-grub" partition. This is basically a small partition in which part of GRUB's code resides. It's not needed on MBR-based computers because GRUB 2 uses some officially-unallocated space instead. The GPT method is actually safer, but the MBR method usually works, in practice.

I suspect that this is what happened:

1. In previous installations, you used GRUB 2 on MBR disks and so had no need of a BIOS Boot Partition.
2. When you installed Fedora, it converted a blank disk to GPT format. Fedora 16 is known to do this; it favors GPT even when it's not strictly necessary. (The Fedora developers are reportedly reversing this decision for Fedora 17.)
3. When you tried to re-install Ubuntu, it saw the GPT configuration and tried to use it. This involved creating a BIOS Boot Partition, or complaining if one wasn't present.

There's absolutely no harm to using a BIOS Boot Partition. One of GPT's advantages over MBR is that GPT doesn't have a 4-primary-partition limit, so devoting 1 MiB of space to a BIOS Boot Partition doesn't chew up precious partition resources. In fact, using GPT has some minor advantages, such as a lack of distinction between primary, extended, and logical partitions (you can create up to 128 partitions by default) and the use of backup data structures and CRCs to help protect against accidental destruction of your partitions. That said, if you want to dual-boot with Windows, using GPT will prevent installing Windows unless the computer has UEFI, rather than BIOS, firmware. This is a big minus. There are also buggy BIOSes out there that won't boot from GPT disks unless you jump through some extra hoops.

If you want to install to an MBR disk, you'll have to remove the GPT data. You can do this with GParted by selecting Device -> Create Partition Table. Be sure that you opt to create an "msdos" partition table (what GParted calls MBR). This will wipe the GPT data and convert to MBR. If you have data you want to preserve, you may be able to do a GPT-to-MBR conversion with my gdisk program, but this doesn't always work. Also, converting in this way will render the disk unbootable until you re-install your boot loader.

I'm battling with the same issue for a different linux OS. Just some brief comments: note that my 'experience' (ha!) is with RAID 0; if you are mirroring from first to second disk (RAID 1) then some of what I suggest below may not apply - others much more experienced than me may help better.

1. you haven't said what RAID (0 or 1) you set up.
2. The RAID'd disks should appear as one device - if you do anything at all to individual disks I suspect you may kill the raid.
3. linux will use either mdadm or dmraid to assemble the raid array, and present the RAID device in /dev/mapper/(something). dmraid is older and reportedly barely /not maintained, but some folk need it if dual-booting with MS-Win on the same RAID. mdadm is the supposedly preferred modern alternative (but won't work on my hardware). From my reading of Ubuntu discussions, I think U uses mdadm behind the scenes for your install.
4. If the raid is recognized/assembled, then in /dev/mapper you should see a file called 'control' and then a file with a name like md (the whole raid device), plus md1, md2, md3 representing any partitions in the whole raid device. The names might be much longer but should resemble each other with different numeric endings. If you've only got the 'control' device and one other device, then I guess you've not created any partitions on the RAID yet.
5. You report it fails with "The RAID arrays all say: /dev/mdx doesn't contain a valid partition table". I suspect that means just what it says; either the raid array has not been assembled (by mdadm) or more likely you haven't created a partition within the RAID on which to do the install. (or you're trying to look on the individual drives rather than looking at the RAID in /dev/mapper)
6. Installations are done to the raid device representing the partition you want to install on, in /dev/mapper/9something). Don't go near /dev/sda or /dev/sdb; they are not the raid device and basically don't exist if you are in RAID 0.

Hope that much perspective helps, and is not out-of-keeping for how Ubuntu does it. Tonyb