Re: GRUB writing to grubenv outside of kernel fs code

[Andrei Borzenkov <arvidjaar@gmail.com>]

18.09.2018 22:11, Austin S. Hemmelgarn пишет:
> On 2018-09-18 14:38, Andrei Borzenkov wrote:
>> 18.09.2018 21:25, Austin S. Hemmelgarn пишет:
>>> On 2018-09-18 14:16, Andrei Borzenkov wrote:
>>>> 18.09.2018 08:37, Chris Murphy пишет:
>>>>> On Mon, Sep 17, 2018 at 11:24 PM, Andrei Borzenkov
>>>>> <arvidjaar@gmail.com> wrote:
>>>>>> 18.09.2018 07:21, Chris Murphy пишет:
>>>>>>> On Mon, Sep 17, 2018 at 9:44 PM, Chris Murphy
>>>>>>> <lists@colorremedies.com> wrote:
>> ...
>>>>>>>
>>>>>>> There are a couple of reserve locations in Btrfs at the start and I
>>>>>>> think after the first superblock, for bootloader embedding. Possibly
>>>>>>> one or both of those areas could be used for this so it's outside
>>>>>>> the
>>>>>>> file system. But other implementations are going to run into this
>>>>>>> problem too.
>>>>>>>
>>>>>>
>>>>>> That's what SUSE grub2 version does - it includes patches to redirect
>>>>>> writes on btrfs to reserved area. I am not sure how it behaves in
>>>>>> case
>>>>>> of multi-device btrfs though.
>>>>>
>>>>> The patches aren't upstream yet? Will they be?
>>>>>
>>>>
>>>> I do not know. Personally I think much easier is to make grub location
>>>> independent of /boot, allowing grub be installed in separate partition.
>>>> This automatically covers all other cases (like MD, LVM etc).
>>> It actually is independent of /boot already.  I've got it running just
>>> fine on my laptop off of the EFI system partition (which is independent
>>> of my /boot partition), and thus have no issues with handling of the
>>> grubenv file.  The problem is that all the big distros assume you want
>>> it in /boot, so they have no option for putting it anywhere else.
>>>
>>
>> This requires more than just explicit --boot-directory. With current
>> monolithic configuration file listing all available kernels this file
>> cannot be in the same location, it must be together with kernels (think
>> about rollback to snapshot with completely different content). Or some
>> different, more flexible configuration is needed.
> Uh, no, it doesn't need to be with the kernels.

It does not need to be *with* kernels but it must match content of /boot
if you want to allow booting from multiple subvolumes (or even
partitions) using the same grub instance. The most obvious case is
snapper rollback used by SUSE. You still have single instance of
bootloader, but multiple subvolumes with different kernels. So somehow
bootloader must know which kernels to offer depending on which subvolume
you select.