On Fri, Jun 15, 2018 at 6:54 AM, Rudolf Kastl <che666@xxxxxxxxx> wrote: > Hello, > > I am curious if any of the upcoming changes also solve the following issue: > > Workstation setup where you want full disk redudancy with raid1 and efi > boot. I've though of two sane options: a. Anything that modifies the ESP is burdened with finding other ESP's (by NVRAM entry, or by parsing various RAID metadata to find the associated ESP for each member device for the array) and updating all of them identically. This means the kernel RPM, shim RPM, and GRUB RPM, must contain this logic. b. A service or daemon that does the syncing. Perhaps it presents a logical device that the above RPMs modify, and the service does the syncing of all relevant ESPs behind the scenes. Or alternatively a "master" ESP is designated which RPMs modify, and the syncing service syncs all other ESPs from the master when a change is detected. The installer right now, against upstream mdadm dev's explicit advice, sets up an mdadm raid1 using (I think deprecated 0.9 metadata format but could also work with 1.0 format). The problem is there's no sync if any modifications are made outside the active array, there's no guarantee the firmware will not write to the ESP, and there's no way to resolve mismatches. It's ambiguous which member device is correct. So it actually magnifies the risk of corruption and thus boot failure. It's a bad hack - that's the diplomatic description. > > * Setting up the OS to be placed on raid1 leaves you with multiple options > (mdadm/btrfs/...) > * Setting up EFI only makes one of those disks bootable > * The EFI partition contians the grub2-efi.cfg file which gets updated every > time a new kernel is installed. Technically this is a symlink thus /etc/grub2-efi.cfg -> /boot/efi/EFI/fedora/grub.cfg And that's for grubby's benefit because for reasons mysterious to me (and upstream GRUB) Fedora likes doing things differently for no good goddamn reason, where the grub.cfg on UEFI is in a different location than on BIOS, which has caused *years* of unreasonable levels of confusion by users why the hell they have to adapt for firmware, rather than developers using abstraction so users aren't so burdened with useless esoterics. > -> Currently the efi partition content (specifically grub2-efi.cfg) has to > be synced manually to the 2nd disk in the raid1 set, to allow booting from > the 2nd disk in case of disk failure of the first disk that contains the > original EFI partition that is mounted under /boot/efi. > > The only potential workaround to avoid manual syncing i know of currently, > is to not use EFI but rather legacy bios boot. Yes... Or use firmware initiated RAID if its metadata format is supported by mdadm. In this case, all member drives are treated as a single device by the firmware in an identical way to the kernel so you don't end up with the problem described above. And this is consistent with systemd-boot developer's position as well, on UEFI only firmware RAID is supported for this use case because of course systemd-boot doesn't read any formats other than what the firmware supports. It is substantially more valid for the installer to take this position and wash it's hands of the problem, rather than doing bad hacks. Yes, it means leaving a number of folks out in the cold if their firmware doesn't support any kind of RAID that is also supported by mdadm -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/LNLKBWZ6Y2TWY2KHXV7AF4UQVPNMJ4KQ/
