(chroot) livecd / # grub-install /dev/sda
/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md0 failed.
Please report this together with the output of "/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>

Because I'm not able to install GRUB2 with metadata 1.2, I need to boot from Ubuntu CD's rescue mode and install the boot loader from there.

In Gentoo, the only way I can boot from a single device "/dev/md0" is when the metadata is 0.90; when I use 1.2 (and install GRUB2 with the help of Ubuntu CD), I see a little bit of kernel messages during the boot and then it stops with the following error message.

I think there's two parts to this. First, ubuntu always uses an initrd so it doesn't depend on the kernel autorecognition of raid devices - it's handled by the normal raid utility after booting the ramdisk. From what I've read in other places, the kernel autorecognition is probably going away rather than getting updated - they're trying to move as much of that stuff out of the kernel as they can.

The second part, is I suspect they've patched grub to allow the newer metadata format. There's no reason you couldn't take ubuntu's grub and build it on gentoo (or even use their binaries like you've tried already). Of course it'd be nice if gentoo incorporated those patches as well.

I think there's two parts to this. First, ubuntu always uses an initrd so it doesn't depend on the kernel autorecognition of raid devices - it's handled by the normal raid utility after booting the ramdisk. From what I've read in other places, the kernel autorecognition is probably going away rather than getting updated - they're trying to move as much of that stuff out of the kernel as they can.

The second part, is I suspect they've patched grub to allow the newer metadata format. There's no reason you couldn't take ubuntu's grub and build it on gentoo (or even use their binaries like you've tried already). Of course it'd be nice if gentoo incorporated those patches as well.

I suspect there's probably a functional difference with the new metadata format, so using it is probably desirable if possible (just a suspicion, perhaps it allows more modifications on a live array, like maybe more resizing or conversion options are possible, as there must be some state and probably a data buffer to indicate how far a conversion has progressed and allow its restart in case the system crashes)

At first I wasn't sure what I was missing in my kernel, so I tried genkernel, but that didn't make any difference; I got the exactly same error message.

Perhaps Ubuntu added something to their GRUB, because when I did "grub-install -v", it returned "1.99~rc1-13ubuntu3" instead of usual "1.99~rc1".

Come to think of it, I wasn't exactly using Ubuntu's GRUB binaries, because I just booted from Ubuntu CD and used their "grub-mkconfig" and "grub-install" to configure and install the bootloader, but all the GRUB-related files in the disk array are still Gentoo's. I'll borrow their files and see what happens.
__
sol

(chroot) livecd # grub-install /dev/sda
/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md0 failed.
Please report this together with the output of "/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>

* The only combination that works without any special treatment is 0.90 + Partition Type as 0xFD + GRUB2 (from Portage). As long as I have MD_RAID456 and BLK_DEV_DM as built-in in the kernel, everything worked.

* When the metadata is 1.2, having a separate boot partition (something simple, such as RAID-1) was the only way to boot. I tried genkernel/initramfs, Ubuntu's GRUB2, voodoo dance, etc, and nothing worked. Considering that Ubuntu is able to do it, I suppose it's doable, but I'm out of clues.

I might come back to it at some other time, but for now, I'm going to stick with 0.90. Thanks everyone.
__
sol

After a lot of fiddling around, I was finally able to boot from RAID-5 + metadata 1.2 + no boot partition. The missing piece was initramfs; basically even though the kernel is loaded successfully, it has no knowledge of "/dev/md0" unless someone else assembles it for the kernel. I mostly followed Initramfs wiki, which is a good read even if you don't deal with RAID-5 and metadata 1.2.

# This is optional if you explicitly assemble /dev/md0.
# But it's always a good idea to make things flexible.
mdadm --detail --scan >> /etc/mdadm.conf
cp -a /etc/mdadm.conf /usr/src/initramfs/etc/

At this point, everything is pretty much ready, except (for some unknown reasons) GRUB2 doesn't want to be installed in /dev/sd[abc]1. Just boot from Ubuntu CD, select "Rescue Mode", assemble /dev/md0, and chroot to /dev/md0. "grub-mkconfig" and "grub-install" should work.
__
sol

After a lot of fiddling around, I was finally able to boot from RAID-5 + metadata 1.2 + no boot partition. The missing piece was initramfs; basically even though the kernel is loaded successfully, it has no knowledge of "/dev/md0" unless someone else assembles it for the kernel. I mostly followed Initramfs wiki, which is a good read even if you don't deal with RAID-5 and metadata 1.2.

# This is optional if you explicitly assemble /dev/md0.
# But it's always a good idea to make things flexible.
mdadm --detail --scan >> /etc/mdadm.conf
cp -a /etc/mdadm.conf /usr/src/initramfs/etc/

At this point, everything is pretty much ready, except (for some unknown reasons) GRUB2 doesn't want to be installed in /dev/sd[abc]1. Just boot from Ubuntu CD, select "Rescue Mode", assemble /dev/md0, and chroot to /dev/md0. "grub-mkconfig" and "grub-install" should work.
__
sol

Thanks for this Mini How-To, it really saved me! It works well even with RAID 0.
Anyway, wiki site is not working, at least, for me.

I just wanted to let you know that you forgot to mention that _we_ have to put a statically-compiled copy of busybox inside the initramfs, contact me if you need more information.

The md driver can support a variety of different superblock formats.
Currently, it supports superblock formats "0.90.0" and the "md-1" format
introduced in the 2.5 development series.

The kernel will autodetect which format superblock is being used.

Superblock format '0' is treated differently to others for legacy
reasons - it is the original superblock format.

I could not find any reference anywhere else on the internet about the md-1 format, so i do not know if it associates with the 1.0 mdadm format. This leaves us (as of 3.6.9) not being able to use mdadm 1.2 superblock metadata as a boot or root partition without having help; that is, you must use initrd of some sort to supply the required software (mdadm) and required libraries.

This forces anyone wanting to boot directly from an image and kernel without initrd to use metablock .90, I believe.[/code]

The kernel builtin driver that assembles arrays (md) does not natively support mdadm metadata 1.2 as of kernel 3.6.9 .

The auto asssembly is deprecated in general. That's what initramfs is there for.

The only reason they don't remove it for 0.90 metadata is that they don't break things in the kernel if they can help it.

Quote:

This forces anyone wanting to boot directly from an image and kernel without initrd to use metablock .90, I believe.

Yes, although you have to be aware of the limits and unreliabilities that come with having metadata at the end instead of at the beginning of a partition. Also partitions may not be larger than 2TB for 0.90.

I use 0.90 (or 1.0) for RAID 1 on /boot only - everything else is 1.2 for me.

Do you think we could convince the kernel doc team to put some notes in the md.txt file saying that further development isn't going to happen?
I only say this as it seems to be the canonical source for info about the md driver, and as much searching on google as i've done (must be using the wrong keywords) i can't find anything other than forum posts with people stating that there will be no further development for kernel autoassemble/md.