http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c9 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fvogt@suse.com) --- Comment #9 from Michael Chang <mchang@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.