Bug 823253

Summary: default entry in grub.cfg is not applied
Product: [Fedora] Fedora Reporter: Andrew <travneff>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: bcl, dennis, mads, pjones, travneff
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-20 14:04:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/etc/default/grub
none
grub.cfg none

Description Andrew 2012-05-20 11:09:53 UTC
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.

SW versions:
grub2-2.0-0.25.beta4.fc17.x86_64

This issue is also mentioned here:
https://bugzilla.redhat.com/show_bug.cgi?id=732058#c21

Comment 1 Mads Kiilerich 2012-05-20 11:53:21 UTC
Please attach your /etc/default/grub and the generated grub.cfg

Comment 2 Andrew 2012-05-20 13:33:53 UTC
Created attachment 585643 [details]
/etc/default/grub

Comment 3 Andrew 2012-05-20 13:35:56 UTC
Created attachment 585644 [details]
grub.cfg

Generated by:
# grub2-mkconfig -o /tmp/grub.cfg

Comment 4 Andrew 2012-05-20 13:40:48 UTC
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.

Comment 5 Mads Kiilerich 2012-05-20 14:04:54 UTC
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.

Comment 6 Andrew 2012-05-20 14:33:26 UTC
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.

Comment 7 Andrew 2012-05-20 14:36:51 UTC
And some other case may be specifying the nested menu entry like GRUB_DEFAULT="0.1".
Is it possible?

Comment 8 Mads Kiilerich 2012-05-20 15:20:09 UTC
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.

Comment 9 Andrew 2012-05-20 16:28:12 UTC
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:

GRUB_DEFAULT="gnulinux-3.3.4-5.fc17.x86_64-advanced-0eec14ac-304b-4aa0-befb-f07555432c88"

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.

Comment 10 Mads Kiilerich 2012-05-20 22:01:04 UTC
(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".

Bug 768106.

> 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.)

Comment 11 Andrew 2012-05-21 08:47:12 UTC
(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.

Comment 12 Mads Kiilerich 2012-05-21 09:32:40 UTC
(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.

Comment 13 Andrew 2012-05-21 09:59:36 UTC
(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.

Comment 14 Mads Kiilerich 2012-05-21 10:17:31 UTC
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.

Comment 15 Mads Kiilerich 2012-05-21 10:44:14 UTC
Please try to remove the private flag.

Comment 16 Andrew 2012-05-21 10:57:57 UTC
Sorry, I can't—the checkbox is disabled for me.