Hi Chris, On 02/04/2014 04:13 PM, Chris Murphy wrote: > > On Feb 4, 2014, at 1:48 AM, David Brown <david.brown@xxxxxxxxxxxx> wrote: > >> 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. > > Both 0.90 and 1.00 are at the end of the partition. > > On a 550MiB disk with the last offset 0x225f0000, I get the start of metadata: > > 0.90 > 225f0000 > > 1.00 > 225fe000 > > In both cases the resulting md device sizes are identical. So if anything 1.00 is very slightly farther back than 0.90, and is a newer metadata version. The Fedora installer use metadata 1.00 along with internal bitmap when creating bootable raid1 arrays. > > This mdadm warning "possible for there to be confusion about whether the superblock applies to a whole device or just the last partition" would only apply if you attempt to make whole physical drives md member devices, which then runs into GPT problems. For one the 1.00 metadata would actually reside within the last 34 sectors of the physical device which is where the backup GPT belongs. Even if you use metadata 0.90 to avoid that, you now have a primary and backup GPT that agree when there is no raid1 active, but then the primary and backup GPT disagree when it is active. So you can't have it both ways with GPT formatted disks on UEFI: both ways meaning a disk that appears valid whether md is active or not. > hmm I didn't think about this previously but why one would use the whole physical drives as md member devices, specially as for the boot disk (the one used to store the bootloader) ? 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
