On Oct 5, 2014, at 2:18 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: > On 10/03/2014 01:04 AM, Chris Murphy wrote: >> >> No. An OSLoader is required, it's an EFI application. Its job is to >> load a kernel and initramfs. The kernel and initramfs could be on the >> ESP (EFI System partition) but this is fraught with limitations. The >> expectation is that the kernel and initramfs are on some other >> partition of the same disk. Of course if you're using GRUB it doesn't >> care and will find a kernel/initramfs off another disk also, or even >> off md raid. > > An option to consider is to compile a kernel using the EFI stub option, > a pre-set command line, and an embedded initramfs. Then the kernel can > boot directly from the EFI FAT partition with *no bootloader*. The > embedded initramfs can support any raid/lvm/partitioning scheme > what-so-ever. Sure but then it means the kernel+initramfs is on FAT32. Ick. And there's no advantage if using maintstream storage options like md raid, lvm, btrfs, xfs, ext234, reiserfs, ufs, zfs, hfs+, ntfs and more, because GRUB2 already understands these things so the kernel can be located on them. For appliances, there could be some advantage since there'd only be one kernel present at a time, no fallback necessary. My Android phone, for example, has 35 partitions. > > If your BIOS can be configured to try multiple boot images, it should be > possible to have true raid fallback without using motherboard or > hardware raid. (Set up md raid1 with metadata v1.0 of multiple copies > of the EFI FAT partition.) I've been meaning to try this…. Problems with this: a.) new Windows 8 hardware might require you boot Windows to get to the feature enabling the firmware setup, because on such hardware USB isn't initialized by default. http://mjg59.dreamwidth.org/24869.html I don't know why we don't have free software to initiate this, but I haven't come across it so far. b.) There's no guarantee the firmware won't write to the ESP, thus rendering the individual md raid members out of sync and without their metadata being updated, i.e. in effect, the logical device they become later, is corrupt. Separately they aren't corrupt, merely out of sync, but you don't have an obvious way of knowing which one. c.) strictly speaking any partition with mdadm metadata should have the linux raid partition type GUID set; not the EFI System partition type GUID. Those GUIDs are mutually exclusive. This is why I'm still not a fan of using mdadm to raid1 an EFI System partition. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
