On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> >> On Dec 2, 2015 8:38 AM, "Reindl Harald" <h.reindl@xxxxxxxxxxxxx> wrote: >>> >>> >>> >>> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski: >>>> >>>> >>>> On Dec 2, 2015 8:15 AM, "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx >>>> <mailto:jwboyer@xxxxxxxxxxxxxxxxx>> wrote: >>>> > >>>> > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski <luto@xxxxxxx >>>> <mailto:luto@xxxxxxx>> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
