[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: booting btrfs
From: |
Michael Chang |
Subject: |
Re: booting btrfs |
Date: |
Mon, 13 Jan 2014 13:13:20 +0800 |
2014/1/10 Chris Murphy <address@hidden>:
>
> On Jan 9, 2014, at 3:03 AM, Michael Chang <address@hidden> wrote:
>
>> 2014/1/9 Chris Murphy <address@hidden>:
>>>
>>> On Jan 7, 2014, at 10:55 AM, Chris Murphy <address@hidden> wrote:
>>>
>>>>
>>>> On Jan 1, 2014, at 10:17 PM, Michael Chang <address@hidden> wrote:
>>>>>
>>>>> We snapshot /boot for kernel and initrd, otherwise the rollback would
>>>>> encounter problem of incompatible userland and kernel/kernel modules.
>>>>> And we need the ability to rollback them in terms of usefulness.
>>>>
>>>> Of course, understood.
>>>>
>>>> core.img is only going to point to one /boot, which may not be the /boot
>>>> snapshot needed for the kernel and initrd. This will be really confusing
>>>> for mortal users. They'd be unlikely to figure it out and understand it,
>>>> without documentation.
>>>>
>>>> If core.img points to the "current" /boot, which it should, that boot has
>>>> the accumulated knowledge of all snapshots, and any recently updated grub
>>>> modules. Choosing to boot a snapshot means using a different /boot for
>>>> kernel/initramfs than what grub is using for its root. I don't off hand
>>>> see a problem with this because it's literally just two files that grub
>>>> loads from a different boot subvolume, found with an absolute path to that
>>>> snapshot. And it also uses rootflags=subvol= to use the matching root
>>>> snapshot.
>>>>
>>>> A separate issue that's not grub's problem is how to deal with the (now
>>>> wrong) fstab entries. systemd looks at fstab and generates mount jobs from
>>>> that; if taught to understand it's booting a snapshot it could second
>>>> guess parts of the fstab. Based on the name of the currently booting root
>>>> snapshot, which systemd definitely knows, it could mount that subvol=
>>>> instead of what's in fstab. It can use name substitution to do the same
>>>> thing with the other subvolume-snapshots that match the root one. Meaning
>>>> all of the snapshots for a system have the same base (re)naming convention.
>>>
>>> Another hiccup. Maybe it's a silly use case. Consider /boot on Btrfs,
>>> multiple-device, raid1 data/metadata profile, UEFI Secure Boot. A drive
>>> dies, and the system needs to be rebooted before a rebuild occurs.
>>>
>>> This works today with /boot on raid1/10 Btrfs. Yes, I manually have to add
>>> a degraded mount option as this isn't automatically done by Btrfs yet. But
>>> the GRUB boot part works. Even degraded, the path to grub.cfg is valid. And
>>> the file system itself keeps multiple copies so there's no work keeping it
>>> current.
>>>
>>> With Secure Boot it's a problem. The signed grubx64.efi has a fixed prefix
>>> location, valid on any computer, to search for grub.cfg, which is on the
>>> ESP. So now we need to have multiple copies of grub.cfg, somehow synced, on
>>> each ESP. Or another solution. If we had a Btrfs subvolumetypeGUID,
>>> analogous to the GPT partitiontypeGUID, and specify that as the baked in
>>> partuuid for a signed grubx64.efi to search for /boot/grub/grub.cfg.
>>
>> Isn't search --fs-uuid sufficient for this task? Or I'm afraid that I
>> didn't understand your problem enough.
>>
>> 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. :)
> Or should it be a future feature of grub-mkconfig to figure out, that two
> grub.cfgs are needed?
No. I don't think grub-mkconfig should be changed at all. Use it in
your UI wrapper scripts to grub-mkcofig would be better.
Regards,
Michael
>
>
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>