http://bugzilla.suse.com/show_bug.cgi?id=1126900 http://bugzilla.suse.com/show_bug.cgi?id=1126900#c5 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com --- Comment #5 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.