Comment # 3 on bug 1156441 from Michael Chang

(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.