Red Hat Bugzilla – Bug 823253
default entry in grub.cfg is not applied
Last modified: 2012-05-21 07:48:01 EDT
There are several entries in my grub.cfg and I'd like to have the second as default. I've set the number in /etc/default/grub as GRUB_DEFAULT and updated grub.cfg with grub2-mkconfig. The number is present in grub.cfg as default, but grub still boots a very first entry.
This issue is also mentioned here:
Please attach your /etc/default/grub and the generated grub.cfg
Created attachment 585643 [details]
Created attachment 585644 [details]
# grub2-mkconfig -o /tmp/grub.cfg
As far as I understand, it might be related with submenu feature added.
Subject issue was absent for me with grub 1.99 in fc16 without submenu "Advanced".
SAVEDEFAULT functionality seems not working too. I mean it doesn't allow to boot the second entry by default after this entry was used.
There is an inherent problem in specifying a number in /etc/default/grub, a number that references the grub.cfg entries that will be created later on. Upstream thus recommends using names/identifiers instead of number. The names/identifiers might be hard to figure out, but once found they are more stable.
The short version is that GRUB_DEFAULT="1" references the second top level entry, but with the current submenu structure there is no second top level entry and grub2 thus use the first entry as fallback.
What you describe is thus expected behaviour given the invalid input.
I'm sorry, but how the names could be more stable taking into account they are changed with every kernel update?
To be more precise, I have kernel and kernel-debug installed. The latter becames the first entry and I don't want to have it as default.
Is it possible to boot non-debug kernel as default without referring to numbers or changing titles?
Alternative could be to disable submenu structure, but I don't see any suitable GRUB_* config option in /etc/grub.d scripts.
And some other case may be specifying the nested menu entry like GRUB_DEFAULT="0.1".
Is it possible?
Kernel updates are handled by grubby. It will modify the grub configuration and thus change the indices of the kernels and perhaps also the default entry.
Sound a bit strange, taking into account it was existing functionality to boot always a fixed entry and now it requires an third-party tool.
Ok, I've checked it now. I set GRUB_DEFAULT in /etc/default/grub to the id of my preferred default entry for now:
then grub.cfg was regenerated by grub2-mkconfig. This default entry was successfully written there.
Then I updated kernel from updates-testing repo. After this, default entry in grub.cfg took value "0".
At this point it is more or less ok while preferred kernel is really the very first entry, but this wipes the id.
Then I've updated kernel-debug too and the default entry becames "1", which is an initial issue.
I'm not sure that it's really a grubby's task, but anyway seems like it isn't possible to boot a non-first entry by default for now.
(In reply to comment #9)
> Sound a bit strange, taking into account it was existing functionality to
> boot always a fixed entry and now it requires an third-party tool.
Fedora has "always" used grubby to patch boot loader configuration files when new kernels are installed.
It is possible that there is a bug in grubby or your usecase isn't covered, but that problem would be different from the problem described here.
> Then I updated kernel from updates-testing repo. After this, default entry
> in grub.cfg took value "0".
> I'm not sure that it's really a grubby's task, but anyway seems like it
> isn't possible to boot a non-first entry by default for now.
It is possible to do that with grub2 - but grubby will perhaps spoil it when upgrading kernels.
Note that the scripts for creating the initial grub.cfg is in /etc, so everything is possible by customizing them ... but obviously grubby can't know how to handle such a custom grub.cfg "correctly".
The best workaround might be to run grub2-mkconfig manually after a new kernel has been installed. (That command is IMO not suitable to be run automatically when a new kernel is installed. That is why something like grubby is needed.)
(In reply to comment #10)
> Fedora has "always" used grubby to patch boot loader configuration files
> when new kernels are installed.
I meant just grub functionality, not a distro-scope one.
> It is possible that there is a bug in grubby or your usecase isn't covered,
> but that problem would be different from the problem described here.
> The best workaround might be to run grub2-mkconfig manually after a new
> kernel has been installed.
Ok, it could be done even automated with yum-plugin-post-transaction-actions, but what is a more proper way? I saw #768106 but it seems a bit different because of it deals with saved entry and subject case has nothing with it.
> It is possible to do that with grub2
Could you please specify what way are you talking about? I've found no possibility to boot second entry with current submenu structure.
(In reply to comment #11)
Why did you make this bug report private?
> Ok, it could be done even automated with
> yum-plugin-post-transaction-actions, but what is a more proper way?
I don't know. But this bug report is not the right place to discuss that.
> > It is possible to do that with grub2
> Could you please specify what way are you talking about? I've found no
> possibility to boot second entry with current submenu structure.
You can do it by specifying the named path to that entry. There might not be a way to do it by position because that would be fragile and unpredictable.
If you would like to change how grub2-mkconfig create grub.cfg then I would recommend getting involved upstream.
(In reply to comment #12)
> Why did you make this bug report private?
Hm, I didn't touch that flag.. Maybe it is related to recent bugzilla update.
> I don't know. But this bug report is not the right place to discuss that.
This is my question---what's the right one. Ok, I'll try to ask it upstream.
grub upstream do not have other solution to kernel upgrade than running grub-mkconfig again - and probably setting the new default kernel with grub-set-default. grub upstream is not familiar with grubby and do for good reasons not like it or care about it.
Discussion of integration of grub2 with Fedora and whether grubby is up to that task should probably happen on the fedora devel mailing list ... but most work and decisions in this area will probably be made by the package maintainer and the RH cabal - all very busy.
Please try to remove the private flag.
Sorry, I can't—the checkbox is disabled for me.