On 04/02/14 09:41, Francis Moreau wrote: > On 02/02/2014 11:57 PM, Phil Turmel wrote: >> On 02/02/2014 05:30 PM, Chris Murphy wrote: >>> >>> On Feb 2, 2014, at 2:34 PM, Francis Moreau <francis.moro@xxxxxxxxx> >>> wrote: >>>> >>>> That's funny because one of the reasons I want to use UEFI firmware >>>> is to get rid of grub (I don't like it and the way it has become >>>> such a bloated beast): since /boot is vfat and has its own >>>> partition, I prefer use a much simpler bootloader such as >>>> gummyboot. >> >> Ditching the bootloader is possible: >> >> http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/ >> > > Well yeah it's possible but not currently usable IMHO. It means that you > need to build your own kernel, include in this kernel the initramfs > image and you need to redo the whole process if you want to change a > single option in the kernel command line. > >> It seems to me that you should be able to create a raid1 v1.0 MD array >> of your EFI support partitions, and put the combined and signed >> kernel/initramfs onto it (mirrored to all member drives). > > Are both v0.9 and v1.0 MD put their metadata at the end of a partition > ? I thought only v0.9 would do that. Yes, it is only 0.9 format that is at the end of the partition. This means that a plain raid1 mirror (with as many disks as you like, as long as they are simple mirrors and not raid10) looks just like a normal partition for other tools. As long as it is read-only, tools that are not raid-aware can use it. For example, grub and lilo can happily boot from a 0.9 metadata raid1 array just like from a normal partition. (Actually, modern grub understands a lot of md raid formats.) The same thing should apply to EFI, as long as it does not attempt to write to the partition. > >> >> Then set the UEFI bios to try each device's ESP in turn. >> >> Untested ... :-) > > I'll do :) > > Thanks > -- 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