On Wed, Dec 2, 2015 at 1:03 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Dec 2, 2015 at 3:16 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> 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. > > Hm. OK. > >>>>>> Frankly, I'd like to see Fedora move away from grub2 even on x86. But I'd >>>>>> also like to see grubby go away. > > Could you elaborate on that grub2 part? Sure. grub2 is really, really complicated. Admittedly, it seems to at least work reliably now, whereas it used to have serious problems. As an example, back in the grub 1 days, menu entries were pretty trivial. With grub 1, I used to set up a password that was needed for non-default interactions with the menu, and it was easy. In grub 2, it seems to be a multi-step process that's complicated for no great reason and makes me nervous that I'll break my boot sequence entirely. IIRC the IMO really nice BootLoaderSpec died, in part because grub2 didn't play along well. (http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) Something like systemd-boot (that which used to be known as gummiboot) or syslinux is much simpler and, especially with EFI, does what's needed quite well. > > How funny! I only edit one because I'm lazy. Grubby propagates the > change to every kernel thereafter. Also, I'm not sure I'd blindly > want an option passed to all existing kernels. Quite often it is > something I'm trying that is new enough to only exist in certain > kernels, or a debug setting I only want on certain kernels. But your > point is certainly valid. > >>>> 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? > > I still think this is an issue. It might be worth focusing on documentation. > True. >>>> 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? > > It leaves existing configs which are known to work alone and doesn't > blow them away if you happen to make a typo in /etc/grub.cfg or > whatever? Breaking a single kernel boot because of a typo is fine. > Making your machine unbootable because you regenerated an entire > config file with a typo just seems silly. Why would you want to > expose users to that? /etc/default/grub IIRC has GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT for this use case. One affects the default entry and the other affects recovery entries. This might be a Debian or Ubuntu-specific thing, though. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
