On Jan 12, 2014, at 10:13 PM, Michael Chang <mch...@suse.com> wrote:
> 2014/1/10 Chris Murphy <li...@colorremedies.com>: >> >> On Jan 9, 2014, at 3:03 AM, Michael Chang <mch...@suse.com> wrote: >>> >>> cat <<EOF > /boot/efi/EFI/<DISTRIBUTION>/grub.cfg >>> search --fs-uuid --set=root `grub-probe --target=fs_uuid /boot/grub` >>> set prefix=(\$root)/boot/grub >>> configfile \$prefix/grub.cfg >>> EOF >>> >>> grub-mkconfig -o /boot/grub/grub.cfg >>> >>> This way we can avoid calling "grub-mkconfig -o >>> /boot/efi/EFI/<DISTRIBUTION>/grub.cfg" and hopefully can get rid of >>> the problem you have. >> >> Yes I think that will work. Do you agree that a GUI installer permitting, >> e.g. /boot on Btrfs raid1, should implement this? > > Honestly I'm not clear about the benefit of it on your case (/boot on > Btrfs) but it would be helpful if you want managing your config path > more in common and general, so use it if you find it useful. :) There are other problems with Fedora that prevent this from being usable now, including grubby which can't update grub.cfg during kernel updates, when /boot is on a Btrfs subvolume. So I have no present implementation, it's a question how to boot from Btrfs raid1 in the future, and have as little duplicative efforts as possible. Also, my argument is that if a GUI installer permits the user to create bootable raid1, that it should also properly configure all drives, and the static ESP grub.cfg, to make the system bootable. Otherwise the user has to do this manually which requires esoteric knowledge beyond most users. If the system really isn't bootable in the face of a disk failure, then I think a GUI installer shouldn't even offer bootable raid1 (Btrfs or otherwise) as an option. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
