On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski
<luto(a)mit.edu> wrote:
>
> On Dec 2, 2015 8:38 AM, "Reindl Harald" <h.reindl(a)thelounge.net>
wrote:
>>
>>
>>
>> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:
>>>
>>>
>>> On Dec 2, 2015 8:15 AM, "Josh Boyer" <jwboyer(a)fedoraproject.org
>>> <mailto:jwboyer@fedoraproject.org>> wrote:
>>> >
>>> > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski <luto(a)mit.edu
>>> <mailto:luto@mit.edu>> wrote:
>>> > > Since the old proposal to have the bootloader automatically
>>> enumerate
>>> > > boot options never went anywhere, can we do the next best thing?
>>> > >
>>> > > Specifically, these days grub2-mkconfig appears to produce output
>>> > > that's functionally identical to what grubby generates. Can
we
>>> switch
>>> > > new-kernel-pkg to just regenerate the grub2 config using
>>> > > grub2-mkconfig instead of using grubby?
>>> >
>>> > I don't think so. Despite the similarity in name, grubby does
more
>>> > than just deal with grub stuff. Namely, it handles bootloaders that
>>> > aren't grub. We're close to having all arches on grub2, but I
believe
>>> > armv7hl won't ever get there and it's a primary arch.
>>>
>>> Could we switch for grub2 architectures and keep using grubby for other
>>> architectures?
>>
>>
>> no - there is a world without grub2
>>
https://fedoraproject.org/wiki/Features/SyslinuxOption
>
> Then let's make the same change across all bootloaders. For grub2, use
> grub2-mkconfig. For syslinux, use whatever Anaconda uses to generate the
> config in the first place.
And you would do that via a single command how? By wrapping it in an
architecture/bootloader agnostic wrapper. Which is what grubby is.
But it's not. grubby does things like adding kernels and removing
kernels. grub2-mkconfig enumerates kernels and generates a config.
> Frankly, I'd like to see Fedora move away from grub2 even on x86. But I'd
> also like to see grubby go away.
Maybe you could start by listing the problems you have with grubby
(and apparently grub2) instead of just saying get rid of it?
Fair enough. Two major problems come to mind:
1. grubby puts the most recently-installed kernel on top.
grub2-mkconfig puts the highest version on top. In the cases where
they differ, I'd argue that the latter is better.
2 .If I want to edit boot options, grubby makes it unnecessarily
painful, and the directions are simply wrong. For example, my
/etc/grub2-efi.cfg says:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
That's grossly misleading. It *was* automatically generated, but it
is certainly not automatically generated on an ongoing basis. If I
change settings in /etc/default/grub, nothing happens. If I actually
want to change boot options, I have to either manually edit every
instance (or somehow, magically, the correct subset of copies) in
/etc/grub2-efi.cfg, which is a real pain and easy to screw up. Or I
can cross my fingers any try to figure out the right invocation to
just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
presumably). Assuming that such an incantation exists (which it does
these days!), one wonders why it's not happening automatically on
kernel upgrades.
To the extent that I do it wrong and grub2-efi.cfg diverges from that
which is implied by /etc/default/grub, etc, we have a mess. This can
happen due to settings editing and presumably due to other things.
In fact, looking more closely, there's already a divergence.
grub2-mkconfig doesn't emit LANG=en_US.UTF-8. The grubby-generated
config has LANG=en_US.UTF-8 on all entries except vmlinuz-0-rescue. I
would argue that that's a bug. If grubby went away or started using
grub2-mkconfig internally, this bug and all bugs like it would become
impossible.
A more minor (from my POV) problem:
3. More critical-path code. grub2-mkconfig must work for Anaconda to
work. ostree requires it, too. But grubby is a separate and
presumably rather more complicated codebase, and it needs to be kept
in sync for kernel upgrades to work, and those are also critical path.
--Andy