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: 2015-12-04 11:28 EST (History)
4 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.

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