On Wed, Dec 2, 2015 at 2:35 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > 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. Hm. Wait. I think there might be a terminology conflict here. Are you specifically referring to grubby the binary, or do you mean grubby the package? Because I was talking about the latter, as it contains new-kernel-pkg, etc. >>> 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. That's a matter of preference. If I have a newer kernel version installed that doesn't actually work, I want the older kernel I _just_ installed to be the default and top entry so my machine boots to something I can use. This happens often when people try rawhide -rcX kernels to test something. Fixing this might be better served by filing an RFE for grubby to change the preference order. > 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 > # TBH, I just edit /boot/EFI/efi/grub.cfg directly. It works fine. > 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. How often are you editing the boot options for _all_ installed kernels? I'm not questioning what you're saying, but my experience tends show people edit boot options for a single stanza which isn't all that arduous. Also, once edited, any newly installed kernel after that picks up the added options auto-magically. > 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. This sounds like a documentation issue? You're looking at the files grub2 installs and trying to follow their advice, but the distro doesn't actually use any of that? > 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. I have a hard time being convinced this is a problem given the number of releases we've done and the number of times it's been a problem in said releases. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
