On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > 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: >>> 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. I'm talking about grubby the binary and grubby the approach of incrementally editing the config rather than regenerating it each time. > >>>> 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. Or file an RFE for grub2 to have an option to use the file timestamps instead of the version for the sort order. In my case, I do a lot of kernel compiling, and I don't like the RPM-provided 4.2-whatever kernels to end up above my 4.4+patches kernel whenever dnf pulls in a new kernel. > >> 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. I do that to. I find it to be extremely tedious and error prone. In comparison, managing /etc/default/grub on the Ubuntu servers I maintain is a piece of work, works every time, and requires no thought about exactly how many copies of the same thing I have to change. And that file exists on Fedora, with the same contents, but uselessly, unlike Ubuntu. Debian/Ubuntu's update-grub tool is wonderful, and it's really quite simple: #!/bin/sh set -e exec grub-mkconfig -o /boot/grub/grub.cfg "$@" Of course, the paths would be a bit different for Fedora. > >> 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. I generally update for all because I don't trust grubby to propagate them if I don't or I edit for all because I'm sometimes fastidious. If I only do one, it's because I'm lazy. > > Also, once edited, any newly installed kernel after that picks up the > added options auto-magically. Depends which stanza I edit in my experience. > >> 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. Certainly the status quo seems to work for the most part, especially if users don't do anything fancy. But Fedora's approach really seems to be considerably more complicated than what everyone else does, and Fedora also packages all the code for the simpler approach already. Other than some people having a preference for a different sort order (which could easily be added to grub2-mkconfig), what's the benefit, if any, of Fedora's incremental update approach? --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
