Comment # 11 on bug 1156441 from Michael Chang

(In reply to Fabian Vogt from comment #10)
> (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)

[snip]

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

This looks like intentional as we have to explicitly touch $saved_entry for
opening the access to $env_block, or it is hidden.

[snip]

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

Just to see my understanding correct, the reason for "need to be there" is the
ro snapshot couldn't allow the file creation in ad-hoc basis, there has to be
pre-allocated before snapshot is taken. The peculiarity is that in ro snashot
we are still able to write grubenv through env_block, but honestly I haven't
tested this case would be free of error as it is really new ..

[snip]

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

Wouldn't the package installation, and hence the environment running %post,
happen in target system ? Or is this a valid concern in transaction update ?

Finally I would limit the condition to btrfs file system used by /boot as we
are only interested in $env_block. Other case grub2-install will not change.

Thanks.