Comment # 10 on bug 1126900 from Michael Chang

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

IMHO the motivation of introducing external block is to workaround the
inability of writing to btrfs filesystem's block, but if the file
/boot/grub2/grubenv itself is read-only then its application is beyond the
scope. In general it means all features require writing to /boot/grub2/grubenv
will fail and I would treat that as a different thing - We have to seek for
another location for writable environment block and btrfs header turns out to
be a candidate (again) for it. And if it doesn't require any writing from grub,
we can also choose to pick another location writable by the linux system.

The next question is "Does health-care require grub to write to the
health_checker_flag?" Because I did not see it happening in existing grub.cfg.

> 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

In any case, I think we have to fix the ro error message as it did not make
sense when the attempt is for writable external block.

> 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

Yes. I could share their feeling but we know life isn't perfect.

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

IMHO #2 and #3 are more or less the same as we are pointing grub for another
grubenv in the grub.cfg. And grub doesn't care what's inside the new grubenv
because it simply loads all variables from it. Personally prefer this solution
than the rest although it will require additional GRUB config file.

I am thinking if we could just drop a new /etc/grub.d/01grubenv_dir with custom
path to file grubenv.

> 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

IMHO the "BIOS boot" is way off, as noone will take care of cleaning it up and
its inadvertent residuals could have side effect. Also the bios boot is a open
common disk property thus it become hard to maintain local data laid on it.

The EFI System may work, but it is specific to EFI and we still end up with the
same trouble on other types of firmware.

> Did I miss any options?

For LVM install, it used to have a proposition to use reserved area in LVM
physical volumes, but grub2 upstream did not accept it and since the joint
development was not public we have little clue for what have gone wrong.