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