On Mon, Jun 18, 2018 at 11:17:50AM -0400, Peter Jones wrote:
On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > On Thu, Jun 14, 2018 at 11:51:33AM -0700, Adam Williamson wrote:
> > > > ** Have a grubby wrapper for backward compatbility that manipulates
BLS files.
> > >
> > > What exactly is the plan for upgrades, here?
> >
> > I *assume* it's what the "grubby wrapper" is there for?
>
> Yeah, I was hoping for more details :)
The grubby wrapper is actually to provide a transition plan to external
scripts and tools that are using grubby, but which we're not aware of.
I wonder if this providing the compat interface is worth the trouble.
If there are those external scripts and tools, it's impossible to know
that they still work with the replacement, unless the replacement
implements everything *exactly* as the original, but that's pretty
much impossible considering that the new scheme is so much different.
So maybe it'd be both less work *and* safer, to just keep grubby as is,
allow existing installations to continue using grubby, and switch
all new installations to not use it at all and not even install it there?
F29 is not that far out actually, and I think it'd be better to devote
available resource to the new implementation, instead of any compat
measures.
Zbyszek
Right now the plan is that it'll be provided as part of grubby,
while we
phase out the grubby code that's so painful. It basically provides
things like telling you which kernel is selected or setting the option
for what to boot next time, without handling the crazy parts of writing
config files or calling out to dracut, or all that stuff.
The general plan for upgrades is a program we've written named
grub2-switch-to-blscfg, which:
- sets GRUB_ENABLE_BLSCFG=true in /etc/default/grub
- creates bls config files for any kernels that aren't already providing
them
- re-runs grub2-mkconfig to generate a BLS-aware grub.cfg
For f28 the plan is that the user can switch by running that manually as
root, or by removing the grubby package, which will call it in %postun.
This gives users ability to switch back in the f28 time-frame in the
event they hit some corner cases we haven't solved or seen yet, and
gives us time to get reasonable feedback before phasing out non-bls
configs. Then, for f29, we'll obsolete grubby itself and only have the
compatibility version.
So that's the upgrade plan.