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 <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Mar 8, 2014, at 8:52 PM, Raul Dias <raul@xxxxxxxxxxx> wrote:
>
>> 2014-03-08 18:20 GMT-03:00 Chris Murphy <lists@xxxxxxxxxxxxxxxxx>:
>>
>>> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
