Replacing grubby with grub2-mkconfig in kernel install process

Ben Rosser rosser.bjr at
Thu Jun 21 15:17:46 UTC 2012

On Wed, Jun 20, 2012 at 12:42 PM, Adam Williamson <awilliam at>wrote:

> As I understood it, the latest version of the proposal involves having
> grubby simply call grub2-mkconfig when it is dealing with grub2. So the
> rest of the 'stack' doesn't change at all.

Well, my proposal is basically this:

If the bootloader is grub2, new kernel entries should be added to the grub2
config (boot menu) in such a way that respects whatever format it is using.

Maybe that means writing a new script to make a diff of the current config
and a fresh one produced by grub2-mkconfig, and figuring out where the
kernel needs to be inserted from that. Maybe it can be done more easily by
modifying grubby to map the current config and figure out where to insert
the kernel from *that*.

Or maybe it's simply calling grub2-mkconfig and installing a fresh config
file. I suggested this, at first, because it seemed the "simplest" thing to
me, but maybe it's not.

Well, the way I see it, that's the solution to the _current_ biggest
> problem we have with grubby/grub2 (it completely nerfing the nested
> format that mkconfig prefers to generate at present). But I see that
> specific problem as only a symptom of a bigger issue, which is that
> upstream currently feels perfectly free to make drastic changes to the
> grub config file format at any time, in stark contrast to how things
> were with grub-legacy, where there was a very stable format we could
> rely on. I feel like, if we stick with grubby, we're kind of stuck in a
> game of whack-a-mole at least until upstream stabilizes the config
> format. We solve this problem, they'll throw us another curveball sooner
> or later...
+1. This is what I was trying to say before.

I suppose we could wait until upstream stabilizes the config before fixing
this at all, but does anyone have any idea when that will be?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list