http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c3 --- Comment #3 from Michael Chang <mchang@suse.com> --- (In reply to Fabian Vogt from comment #2)
(In reply to Michael Chang from comment #1)
(In reply to Fabian Vogt from comment #0)
Some grub2 configs rely on being able to read and write certain environment variables (like health_checker_flag), but this only works if grub2-editenv was called previously. grub2-install should take care of setting up the env_block for systems which need it, if it doesn't exist yet.
The real usage of grubenv is really out of control by the grub-install as it is specific to application by dropping it's own snipped to grub-mkconfig or via custom.cfg to source it somewhere.
Yes, that's exactly my point. grub2-install does not how how and whether grubenv is used, so it has to make sure that it is fully available. Without initializing env_block, that is not the case.
I beg to differ. We cannot know how grubenv is used specifically by the time grub2-install is invoked so it could conflict with applications with specific purpose to that file later. For eg, recently upstream accepted the grubenv to be a symlink than regular file and grub2-editenv would chase the link for content ..
If I remember correctly Ignaz has a solution to the health_checker_flag issue by using a writable subvolume in combination of grub script snippet. Would this be related or we are having other issue ?
It's tangentially related, having grubenv moved below /boot/writable allows initializing env_block even with a read-only /boot. grub2-install isn't called from that context though, so that shouldn't really matter.
I am confused as this seems to conflict with "grub2-install should take care of setting up the env_block for systems ..." from description above. Here you are with "grub2-install isn't called from that context though, so that shouldn't really matter." Thanks. -- You are receiving this mail because: You are on the CC list for the bug.