Bug 1287854 - RFE: consider regenerating config instead of incrementally updating it when possible
RFE: consider regenerating config instead of incrementally updating it when p...
Status: NEW
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-02 15:40 EST by Andy Lutomirski
Modified: 2018-03-12 07:00 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Lutomirski 2015-12-02 15:40:53 EST
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).

2. Different order.  grub2-mkconfig sorts by version.  grubby implictly sorts by recency.  Some people may prefer recency, and grub2-mkconfig could be taught to sort by ctime or rpm -qf --queryformat '%{installtime}' or similar, possibly configurably depending on a config option somewhere.

Doing this could reduce grubby's complexity and would give some benefits IMO:

 - It would bring Fedora more in line with other distros (makes looking for docs easier).

 - It would make editing boot options and other preferences simpler (just change /etc/default/grub, which Fedora already provides, rather than trying to figure out which subset of the copies in /etc/grub2-efi.cfg need changing).

 - It would prevent new bugs like the LANG= mismatch from being possible.

grubby could consider a similar change for other supported bootloaders, and shipping a tool called 'update-grub' to trigger manual config regeneration could be nice, too.
Comment 1 Harald Reindl 2015-12-02 15:51:32 EST
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
Comment 2 Harald Reindl 2015-12-02 15:59:01 EST
"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
Comment 3 Andy Lutomirski 2015-12-02 16:57:18 EST
(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.
Comment 4 Andy Lutomirski 2015-12-02 17:01:24 EST
See bug 1287876 for an RFE to allow RPM installation order to be respected in grub2-mkconfig.
Comment 5 Harald Reindl 2015-12-02 17:03:59 EST
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
Comment 6 Andy Lutomirski 2015-12-02 17:08:30 EST
I should add that I'd consider a full implementation of BootLoaderSpec to be even better than switching to grub2-mkconfig for kernel enumeration.
Comment 7 Marcos Mello 2015-12-04 10:03:19 EST
(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
Comment 8 Andy Lutomirski 2015-12-04 11:28:33 EST
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.
Comment 9 kevin martin 2018-03-08 17:09:32 EST
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).
Comment 10 Harald Reindl 2018-03-08 17:18:39 EST
> 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)
Comment 11 kevin martin 2018-03-08 18:40:18 EST
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.
Comment 12 Harald Reindl 2018-03-08 19:16:27 EST
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
Comment 13 kevin martin 2018-03-09 12:17:24 EST
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.
Comment 14 Harald Reindl 2018-03-09 12:32:55 EST
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
Comment 15 kevin martin 2018-03-09 12:46:51 EST
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.
Comment 16 Harald Reindl 2018-03-09 13:41:21 EST
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"
Comment 17 kevin martin 2018-03-09 13:57:17 EST
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.
Comment 18 Harald Reindl 2018-03-09 14:49:50 EST
than for the sake of god fix the docs
Comment 19 kevin martin 2018-03-09 16:46:38 EST
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.
Comment 20 Harald Reindl 2018-03-09 19:50:57 EST
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
Comment 21 kevin martin 2018-03-09 22:38:15 EST
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.
Comment 22 John Haxby 2018-03-12 06:38:24 EDT
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).
Comment 23 Harald Reindl 2018-03-12 06:45:28 EDT
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
Comment 24 John Haxby 2018-03-12 07:00:23 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.