Comment # 9 on bug 1156441 from Michael Chang

Alri(In reply to Fabian Vogt from comment #8)
> (In reply to Michael Chang from comment #7)
> > Think it twice, I am still reluctant to patch grub2-install as the potential
> > conflict in usage of /boot/grub2/grubenv with other application that expects
> > it to be otherwise, like symlink or such.
> 
> grubenv should be managed by grub only, if other tools break it later that's
> IMO a bug in those tools. As long as grub2-install only creates grubenv with
> env_block if it didn't exist before, I do not see any problem here.

In my opinion there's no clear cut here as to what manages grubenv. It is an
open storage file for persistent settings to grub.cfg. Any application or user
could manage it through grub2-editenv, for initialization just calling
"grub2-editenv create ..." or simply any command would silently initialize if
not there yet.

> 
> > Shouldn't the application whichever requires the /boot/grub2/grubenv to run
> > holds the responsibility to initialize it ? What's the difficulty doing that
> > ?
> 
> I've got three reasons:
> 
> 1. grubenv is a core feature of grub, which should always be available anyway

But is also not mandatory .. as system could run without it. Certain function
would require it and was created on an ad hoc basis.

> 2. Only grub2-install knows where and how (btrfs vs. non-btrfs) to
> initialize it

I think grub2-editenv was taught to know how to do so.

> 3. How should applications do that? The rpm's %post script might not even
> run on the target system. This is the case for kiwi image builds for
> instance.

How about calling "grub2-editenv create ..." or "grub2-editenv set key=val ..."
in %post ?

Thanks.