On 10/05/2014 04:22 PM, Chris Murphy wrote: > > On Oct 5, 2014, at 2:18 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: [trim /] >> 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. Good to know, but totally immaterial to the boot sequence I'm recommending. Boot linux of of an EFI FAT and let linux initialize the USB hardware in its own good time. Matthew Garrett's post is really all about how to get linux into the Win8 box in the first place. Once there, manipulate the boot sequence as you please. > 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. This is a very good point. In fact, I withdraw my recommendation to raid these partitions. Simply have one on every disk the BIOS could possibly boot from, and place an EFI bootable kernel in each one (with embedded initramfs). > 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. The former is not true at all--mdadm does not care *at all* what partition types are set. Grub might care, but it's moot if you don't use Grub. :-) > This is why I'm still not a fan of using mdadm to raid1 an EFI System > partition. One further point: the failure decision tree is nicer if you boot directly into a kernel. 1) Bios locates and attempts to boot from 1st configured kernel image 2a) Corrupted image or other disk error blocks complete load of kernel image--bios moves to next EFI choice (possibly on a different disk). 2b) Successful EFI kernel load, boot encounters missing/corrupt root FS--kernel drops to initramfs rescue shell versus: 1) Bios locates and attempts to boot from 1st configured grub image 2a) Corrupted image or other disk error blocks complete load of grub--bios moves to next EFI choice (possibly on a different disk). 2b) Successful EFI grub load, grub encounters corrupt config or grub module--drop to grub shell 2c) Successful EFI grub load, kernel & initramfs load by grub, boot encounters missing/corrupt root FS--kernel drops to initramfs rescue shell I haven't had time to set it up yet, but the clear reduction in points of failure is compelling. Faster boot is just icing on the cake. Phil -- 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
