Chris,

thank you for a good explanation! However, if I use
partitions(/dev/sda1, /dev/sdb2, etc) as block devices and thus write
mdadm metadata v1.2 not to gap after the MBR, but to an area from 4KB
from the beginning of the partition, then how is it ensured that I
don't overwrite anything? I mean mdadm isn't using regular OS calls
for writing data to file-system, is it? I understand that it writes
this metadata similarly to dd utility and doesn't understand if it's
overwriting any files or not? Or the other way around, if I create a
file-system(for example ext3 or ext4), then how does the mke2fs
utility know that it should not use the area at the beginning of the
partition?



regards,
Martin

On 3/9/14, Chris Murphy [off-list ref] wrote:

On Mar 8, 2014, at 8:52 PM, Raul Dias [off-list ref] wrote:

quoted

2014-03-08 18:20 GMT-03:00 Chris Murphy [off-list ref]:

quoted

If BIOS, yes grub-install to each member disk. If UEFI, install to one,
and then manually create and copy to the others (for now).

Simply mounting eachUEFI vfat partitions and copy the files is enough?
Does it need to be updated on every new kernel update (grub menu
item)?

If the grubx64.efi (core.img) is created by grub-install, it'll look for
grub.cfg in the usual location, /boot/grub, by volume uuid.

If your distribution supports UEFI Secure Boot, then it installs a generic
prebaked core.img that's signed, and therefore doesn't know the volume uuid
to look for. At least on Fedora, it searches for grub.cfg in the local path
for grubx64.efi, which of course seems to cause the problem that now there's
a grub.cfg that must be updated on each member drive, any time there's a
kernel update. Instead, edit the ESP grub.cfg like this:

# DO NOT EDIT THIS FILE
# FORWARDS TO THE REAL GRUB.CFG
{
	search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2
--hint-efi=hd1,gpt2 --hint-baremetal=ahci0,gpt2
8af1d5ed-3b48-4cf0-b397-373bf006c625
	configfile /boot/grub2/grub.cfg
}

The fsuuid at the end of the search line comes from one of the menu entries
in the existing grub.cfg, which is how it knows where to find the kernel and
initramfs. Since /boot/grub is pretty much always on that same volume, the
same fs uuid applies. The above is the entire grub.cfg. Copy that and all
binaries to all member drive ESPs. This grub.cfg never needs updating.

So now all member drives have the ability to load grub and a grub.cfg that
merely forwards to the real grub, which is on a mirrored /boot. Use
grub-mkconfig -o /boot/grub/grub.cfg to write out a new grub.cfg that the
above one will forward to.


Chris Murphy

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html