Comment # 5 on bug 1126900 from Fabian Vogt

(In reply to Ignaz Forster from comment #4)
> (In reply to Michael Chang from comment #3)
> > In this case, setting health_checker_flag=0 should require writing to
> > /boot/grub2/grubenv and the error is sensible if ongoing task is on
> > read-only file system. I really don't know anything else to expect from
> > btrfs, since it is no difference to other file systems in this regard.
> 
> Indeed, that was something I hadn't realized until recently: While GRUB
> itself is *always* able to write the GRUB environment block (on supported
> file systems at least), it may not be possible to do so from userspace - in
> this case because the file system is mounted or flagged read-only.
> Due to this one workaround I was thinking of is to use a completely
> different file to store the GRUB environment block, e.g. some file below
> /var, as /var always has to be writeable. From what I can see the problem
> would be to find the correct partition or subvolume containing that file
> from within GRUB. I'll have to experiment with this a bit.

/var might not exist, so I suggest a subvolume with a fixed path below
/boot/grub2. It would always be on the same partition as /, which is not
necessarily true for /var and can also be found using just the knowledge of the
filesystem grub already has.

> Regarding Jiri's question about the split into two sections: What I also
> don't understand is why /boot/grub2/grubenv is used on Btrfs at all.
> Couldn't all data be stored into the Btrfs header directly? The contents of
> /boot/grub2/grubenv are inconsistent on Btrfs systems anyway, as GRUB won't
> update that file.

IMO the best option currently as it's not too complex to implement and it would
also not need any migration path. Only env_block would be part of the grubenv
in the file system and all other variables would be read from/written to the
header.