Comment # 10 on bug 1156441 from Fabian Vogt

(In reply to Michael Chang from comment #9)
> 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.

Exactly that is not the case. To actually initialize env_block, one has to
"grub2-editenv delete saved_entry". YaST sets saved_entry during installation
"by accident", which is the only reason grubenv with env_block is actually
there
after regular installation.

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

Not necessarily. For health-checker to work properly, grubenv + env_block
need to be there. Currently there's a nasty error message when booting images
with health-checker installed. The system boots anyway as there's a timeout,
but without health-checker support.

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

Correct, but grub2-editenv is not called by grub2-install. That's what this bug
report is about.

> > 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 ?

Point 3 is about why that does not work. Please explain how you would work
around %post not having access to the target btrfs filesystem.

> Thanks.