no, no and no again

the whole purpose how grubby acts is to *not touch* manually changed entries of existing boot entries just because a new kernel got installed

"regenerating config instead of incrementally" leads in change *intentional* differences of options when someone tries to debug kernel problems and much more worse: a bug there would render *all* boot options unbootable instead only the last installed one

frankly one can even raise "installonly_limit" by intention and have the same kernel version with *multiple* options - that all would be erased by try out if a newer build fixes the problem

now you can say: that's not a problem for the ordinary user
i say: the ordianry user don't touch kernel options at all

(In reply to Harald Reindl from comment #1)
> no, no and no again
> 
> the whole purpose how grubby acts is to *not touch* manually changed entries
> of existing boot entries just because a new kernel got installed

/etc/grub.d/40_custom exists for this purpose.

Certainly we shouldn't switch from incremental changes to regenerating the whole config for existing installs.  But we could do it for fresh F24 or F25 installs, and we could have a simple path for users to switch over (maybe even automatically) and to deprecate the old approach if desired after a while.

See bug 1287876 for an RFE to allow RPM installation order to be respected in grub2-mkconfig.

interesting: in one post you say grub2 and all it's configuration is complicated and error prone while you now say "/etc/grub.d/40_custom exists for this purpose"

you don't need "/etc/grub.d/40_custom" when you manually edit grub2.conf


"Certainly we shouldn't switch from incremental changes to regenerating the whole config for existing installs.  But we could do it for fresh F24 or F25 installs" - how do you distinct and how does it matter when you play around with boot options because a random future kernel update makes troubles you want help to debug?

the point is that "regenerating config" is a damned bad idea - you have *no business* to touch any of my existing boot configurations just because a new kernel update got installed

for ordinary users that's a non-topic at all and you spit expierienced users which know what they are doing straingt in their face

I should add that I'd consider a full implementation of BootLoaderSpec to be even better than switching to grub2-mkconfig for kernel enumeration.

(In reply to Andy Lutomirski from comment #0)
> grub2-mkconfig has customization hooks, and Fedora's initial grub2 config
> comes from grub2-mkconfig.
> 
> On an install that's seen a couple of kernel udpates, the differences
> between grub2-mkconfig's output and /etc/grub2-efi.cfg breaks down into two
> categories:
> 
> 1. Differences within entries.  This seems limited to LANG=, and I would
> argue that the difference is a bug that should be fixed (in grubby, grub2,
> or elsewhere, depending on which is right and where the issue lies).

https://bugzilla.redhat.com/show_bug.cgi?id=1098749

Looking at the patch in there and looking at new-kernel-pkg, there is a lot of code that, if it works correctly, simply produces identical output to grub2-mkconfig / whatever else Anaconda uses on other platforms.

It really seems to me that consolidating this would make sense.

One could make the argument that nobody should be DIRECTLY modifying the grub2.cfg file anyway but should be creating their custom configs using the /etc/grub.d/40_custom file as it's meant to be used so that using grub2-mkconfig in the kernel rpms not only gives one new entries for new kernels with whatever defaults one put in /etc/default/grub but also puts back the "special" configs that the end-user wants.  A good example of this is with the Spectre/Meltdown patching that companies are doing (mine included) where we go put in special options in /etc/default/grub, install new kernels that should take advantage of those entries, only to see the grub2.cfg *NOT* built with those parameters in place as they should be if the proper tool was used to build the grub2.cfg file and the "special" entries were put in the proper place so they were persistent over updates.  I would like to see grub2-mkconfig put in the kernel rpms to rebuild the grub2.cfg and quit coddling those people who think that modifying system files directly is the correct way to admin their machine(s).

> I would like to see grub2-mkconfig put in the kernel 
> rpms to rebuild the grub2.cfg and quit coddling those 
> people who think that modifying system files directly 
> is the correct way to admin their machine(s)

keep your fingers from my configs - full stop

when debugging some kernel problem and each time i try another build you fuckup my config where i also try different options for differnt build the only thing that you gain is that i no longer test new kernel versions (and yes that's real world, just look at the timestamps when kernel builds are finished and when i gave karma - often even the maintainer don't know the build has finished at this point in time)

So put your config mods where they are supposed to be and don't be a lazy admin/developer.  Just because you choose not to do things the right way doesn't mean the rest of the world should suffer for your laziness and arrogance.

the only arrogance here is yours or how do you imgaine differnt kernel with different options with grub2-mkconfig - so please until you understand what others explain you refrain from answer again

As I read it, the /etc/grub.d/40_custom file allows you to add whatever custom menu entries you want to have in the grub2.cfg file, and it will persist from rebuild to rebuild of the grub2.cfg.  Here's a link for your viewing pleasure: https://help.ubuntu.com/community/Grub2/CustomMenus.  that would be the *proper* way to keep your custom entries custom without breaking the functionality of the grub system for everybody else.

yeah, completly hardcoded entriues which don't scale with removed kernels and son on - given that i rub 45 Fedora installs (including all test-instances) and most of them date back to 2008 i call "without breaking the functionality of the grub system for everybody else" bullshit

you can't argue scalability when you are arguing that you need to hardcode stuff in the .cfg file!  What's the difference between hardcoding in the cfg directly or hardcoding in the 40_custom and rebuilding the .cfg?  by doing it the 2nd way the correct tools for the job of installing and maintaining kernels on user/customer sites can be performed and *still* allow you the ability to have your customizations.  Your argument is self-serving at best and obstinate at worst.  There's a reason for the grub.d files and /etc/default/grub file and just because you don't use them doesn't mean that the grub build system should be engineered around you.

the difference is that a new testing kernel inherits all params from the latest one without touching others - if you don't gasp that I can't help you but after using Fedora since FC3 i can assure you that every time I touch a distribution not having grubby that way I want to puke

your stupid "around you" arguments are pointless because it has always been that way and if it ain't broken don't fix it - if it's broken for border cases i never have seen over 24 Fedora releases fix that border cases but don't fuck up every body else

what is the real problem you try to solve? 

sounds like "have solution, seeking for problem"

the problem is that the documentation tells you to set kernel options in /etc/default/grub but that when new kernels get installed those options don't get picked up because new-kernel-pkg ignores /etc/default/grub.  when you have 1000's of linux machines running el7, ol7, centos7, and the like you want to be able to trust that the doc's are correct and that kernel settings will be picked up when a new kernel is installed.   However, that's not the case since instead of using grub2-mkconfig to build grub2.cfg, new-kernel-pkg is used and ignores the /etc/default/grub.

than for the sake of god fix the docs

fix the docs?  if everyone followed the docs as they should then this wouldn't be an issue.  why have two methods of gen'ing the grub configs; either use grub2-mkconfig or fix new-kernel-pkg to pick up the /etc/default/grub stuff and add it to the necessary lines in the grub config the way it should.

they current behavior of grubby dates back way longer than /etc/default/grub and grub2 at all - you are only too young - again if it ain't broken don't fix it

you still missed to mention REAL WORLD problems

Ah yes, more of the Reindl arrogance.  You just never tire of it do you?  Can't say how many mailing lists I've seen you on and your behavior never changes which is amazing since you've been suspended from more than one for periods of time for your boorishness.

  I've been doing Linux administration since the early 2000's and whether or not "the current behavior dates back" is like saying, eh, the bug has always been there so why correct it?  That's why a number of bugs on bugzilla that are reported are reported for version after version after version and never get fixed; complacency and arrogance.  Regardless, if it's up to you to correct this it's obvious it won't be so, since nobody else cc'd on this bug is commenting, I'm assuming it won't be.

grubby and /etc/default/grub (+ grub2-mkconfig) are in some conflict here.

Back in the old days of legacy grub then there wasn't any choice: there wasn't a grub-mkconfig.  The initial /boot/grub/grub.conf was created by anaconda and then any further changes were edited in by hand.  (Woe betide you if you forgot to put an important change on the default kernel.)

And now we have grub2.  grub2 config files are waaay more complex than legacy grub config files but fortunately we have grub2-mkconfig and grub configuration has moved from /boot/grub/grub.conf to /etc/default/grub for most purposes and 40-custom for the complex hand-crafted boots.

So "keep your fingers from my configs" is now applies to those files, not /boot/grub2/grub.cfg which starts "# DO NOT EDIT THIS FILE".  So your carefully constructed tweaks to grub.cfg are contradicting that shouty instruction, but hey, we have grubby that does that for you so you can pretend you're not really editing the file.

Hmmm.

Really, I think, the time has come to address the problems with things like boot order (bug 1287876) and finally retire grubby.  It served its purpose well for legacy-grub but now we need to move on.

If we start fixing the problems with grub2 then we're going to break grubby again so now is the time to either retire grubby or have it work with the real config file (/etc/default/grub).

the main problem is that re-generate /boot/grub2/grub.conf from scratch all the time may lead *every* installed kernel entry unbootbale, even the last known good which with the current behavior would be untouched

Well, yes, that's true.  You can also do that by carefully editing grub.cfg to make every kernel unbootable as well(*).  The fact remains, though, by editing grub.cfg you're editing a file that is marked "DO NOT EDIT" so unless you're going to teach grub2-mkconfig to somehow know which changes need to be overridden and which ones should stay you should not be editing that file *at all*.

Either grubby needs to retire or grubby and grub2-mkconfig need to be made consistent so you can make changes with either.

(*) Not that I've ever done that, of course :)

(In reply to John Haxby from comment #24)
> Well, yes, that's true.  You can also do that by carefully editing grub.cfg
> to make every kernel unbootable as well(*).  The fact remains, though, by
> editing grub.cfg you're editing a file that is marked "DO NOT EDIT" so
> unless you're going to teach grub2-mkconfig to somehow know which changes
> need to be overridden and which ones should stay you should not be editing
> that file *at all*.
> 
> Either grubby needs to retire or grubby and grub2-mkconfig need to be made
> consistent so you can make changes with either.
> 
> (*) Not that I've ever done that, of course :)

Completely agree. There is yet another case where using grubby results in a broken config by design: if you have Xen installed, you have multiple entries for a single kernel (one with Xen, one without). Grubby adds only one entry (if the missing one is the Xen one, it's easy to miss as it doesn't have kernel version in its menu title).

Let me summarize arguments for and against grubby:

For grubby:
 - keeps user modifications made in a file clearly marked with "DO NOT EDIT THIS FILE" (#c10)
 - in case of hypothetical bug in grubby, there is a chance not all the entries will be broken (unless the bug results in a whole file broken, like an empty file, or a syntax error like in Bug #1509515)
 - grubby use installation order, instead of version order (which may or may not be desirable)

Against grubby:
 - grub2-mkconfig respects /etc/default/grub, which is the canonical place for putting kernel options (see #c17 and #c9 for examples why it's important)
 - if grubby works correctly, should produce the same output as grub2-mkconfig, so there is very little point in maintaining duplicated complexity (#c8, #c22)
 - grubby does not handle multiple entries per kernel properly (Xen + non-Xen for example, or btrfs snapshots Bug #1457509)
 - grub2-mkconfig provide also canonical place for custom entries (/etc/grub.d/40_custom), so there is even less reason for manual grub.cfg modification (#c13)
 - there are multiple bugs in grubby, resulting in incorrect/incomplete menu entries being added/removed (listing just few open ones: Bug #1098749, Bug #1573087, Bug #1576093, Bug #1509515)

For me it looks like grubby (with grub2, not saying anything about other boot loaders) solves non-real-world problems and produces real-world problems.
Can kernel RPM scripts results in a call to grub2-mkconfig, finally?

The grubby tool has not been used anymore for several Fedora releases. Now the boot menu entries are stored in as
BLS snippets in the /boot/loader/entries/ directory. The grub config shouldn't be regenerated in most cases and
don't contain any menu entry anymore.