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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/LVY2QTZWFRGFWFRJ3A2CINAUZXS3PLGC/
