Re: booting btrfs

[Chris Murphy]

On Jan 12, 2014, at 10:13 PM, Michael Chang <address@hidden> wrote:

> 2014/1/10 Chris Murphy <address@hidden>:
>> 
>> On Jan 9, 2014, at 3:03 AM, Michael Chang <address@hidden> 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