Re: Replacing grubby with grub2-mkconfig in kernel install process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2012-06-20 at 09:21 -0400, Peter Jones wrote:
> On 06/19/2012 11:57 PM, Adam Williamson wrote:
> > On Tue, 2012-06-19 at 23:28 -0400, Ben Rosser wrote:
> >
> >>
> >> So far, the only actual arguments against this (specifically, the
> >> above solution to the problem) I've heard is that it breaks being able
> >> to configure /boot/grub2/grub.cfg by hand. But that's the idea behind
> >> grub2, for better or worse. The documentation specifically tells you
> >> NOT to edit that file, but to instead edit configuration in /etc.
> >>
> >> Most of the other arguments raised in response to this seem to have
> >> really been about grub2 itself, and if Fedora has to use it, so.. are
> >> there any other thoughts on the actual matter at hand?
> >
> > grub2-mkconfig is inherently a more 'destructive' operation than grubby,
> > is really my only thought. But I wouldn't mind the change much at all.
> > pjones' opinion would be the most valuable to have, I guess.
> 
> I really don't see what the point would be.  We're going to have to keep
> grubby for various reasons, not least pvgrub.  So switching to using
> grub2-mkconfig to update grub2 config files has numerous downsides, most
> obviously:
> 
> 1) it means new-kernel-pkg would need to be even more complex

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.

> 2) it means per-kernel command line changes aren't a thing we can really
>     support, which means if for some reason you need a command line option
>     to boot with one kernel that's installed and it needs to /not/ be there
>     for another, we'll be writing a wrong config every time.

It's not possible to do this through grub2's own mechanisms?

> It seems to me that a lot of people are advocating to switch from one thing
> they don't understand to another thing they don't understand.
> 
> I think what's actually needed is a small patch to grubby to make it keep
> track of the bounding block the current default is in and add the new
> bounding block there, so that we don't accidentally change the cosmetic
> properties of the grub2 config file, which seems to be what's causing the
> most aggravation here.  It probably wouldn't be difficult, but if you're
> waiting for me to do it, cosmetics are currently pretty low on my priority
> list.

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...

> So I'd be really glad to see a grubby patch from anybody who's commented
> on this list.  It shouldn't be a lot of code or particularly difficult. If
> somebody wants to work on it, I'd be glad to help them out with any
> difficulties they come across.

I guess Mads might be able to do it?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux