Comment # 9 on bug 1126900 from Ignaz Forster

(In reply to Michael Chang from comment #8)
> Scratch that - It has been done already according to the changelog. I'm
> sorry for not keeping it up correct on my mind

No problem, thanks for taking care of it!

> Now I am getting to understand your proclaim as this could be "just a
> cosmetic problem" .. The next question is do you need anything from me in
> order to close the ticker here ?

That's a good question, as I'm not sure what the best way to solve this problem
would be.

My hesitation is partially caused by the fact that while playing around with
our KIWI images I discovered another directly related problem: KIWI do not
contain /boot/grub2/grubenv at all.
Even on regular installations it is more or less a side effect that
/boot/grub2/grubenv is generated at all *during installation*: In
https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/sections.rb#L46
`/usr/sbin/grub2-set-default` is called. That script will in turn call `grubenv
unset ...` towards the end, which will incidentally trigger the generation of
the grubenv file. That doesn't seem to be a conscious creation of the file...

Now what's happening if the file isn't there?
On rw file systems the file will just be created if one of a small set of
accepted variables is set / deleted. On ro file systems the file obviously
can't be created retroactively. grub2-editenv doesn't like that at all and will
abort before even trying to write to the btrfs header. So with read-only root
files systems we not only have that cosmetic problem, but writing the variables
may fail completely.


I can currently see the following options to solve this:

1. Most obvious fix
- Don't print the error message in grub2-editenv if the data was written into
the btrfs meta data successfully.
- Make sure that KIWI is somehow triggering the generation of grubenv.
Pro: simple to fix in grub2-editenv
Con: Shouts "hack" loudly; KIWI's code isn't really prepared for this, as on
UEFI system it's just copying the modules without even calling `grub2-install`
(Note: I just realized that Yomi also added that call to `grub2-set-default`);
no generic solution, but works for all *SUSE use cases

2. Use different path for grubenv
- Use another location which we know will be writeable, e.g.
`${config_directory}` if it's set and
`${prefix}/${grub_cpu}-${grub_platform}/grubenv` (which may translate to
/boot/grub2/i386-pc/grubenv or /boot/grub2/x86_64-efi/grubenv on x86)
otherwise.
Con: Needs migration; avoids snapshotting of GRUB environment variables (but
that may even be desired?); also a hack, there's no guarantee those directories
will stay writable

3. Use different path for this one variable
- Like 2, but only save this one variable into a different file
- Package would create an additional GRUB config file
Pro: May be minimally invasive and still work?

4. Store grubenv in "BIOS boot" / "EFI System" or custom GRUB partition
- The current GRUB environment block implementation has several limitations
(i.e. doesn't work with LVM, software RAIDS or some file systems); it may be
worth rethinking on how it could be stored more universally.
- It may be possible to use the "BIOS boot" / "EFI System" partitions for it if
available.
Pro: May provide a clean, distribution independent solution, without any hacks
Con: Lots of work and discussion necessary

Did I miss any options?