Bug 736188

Looks like it can't handle:

if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="${saved_entry}"

saved_entry is set in /boot/grub2/grubenv, e.g.:

# cat /boot/grub2/grubenv 
# GRUB Environment Block
saved_entry=Fedora Linux, with Linux 3.1.0-0.rc8.git0.0.fc16.i686
#####################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

This looks like fun.

At least this goes away after the first kernel update and we get:

set default="0"

Bug 732058 is the same issue from another perspective.

I've hit this bug.
I'm using grubby --default-kernel as RPM %post section which return void.
As this case is not handled by my script, it fails. (xorg-x11-drv-nvidia FYI).

The installation was done with the update repository enabled from x86_64 DVD
default installation (as of 20111230).

This is a big problem for those of us, blasphemers, who dual-boot but want to have Windows starting by default.
I have followed the directions posted here:
http://fedoraproject.org/wiki/GRUB_2
It works, but only until a kernel is installed or erased. Grubby then thinks it knows better, and overwrites
set default="${saved_entry}"
with
set default="0"
This is very annoying - I have set this on my dad's computer, but he is not enough savvy to run grub2-mkconfig every time a new kernel update comes out (which also backfires since it removes nouveau.modeset=0 and rd.driver.blacklist=nouveau, but this is a different bug).

Julian, the problem you (and comment 2) mention might be related to the core issue reported here, but it is different and better tracked on for example bug 768106.

Mads, thanks for the info. I've CCed myself on that bug.

Bumping the Fedora version number so this doesn't get auto-closed

Still present in F19.

Please try the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=5680227 , grubby-8.27-1.fc20, which should fix this issue.

Sorry, going to wind up being http://koji.fedoraproject.org/koji/taskinfo?taskID=5680356 instead.

grubby-8.27-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grubby-8.27-1.fc19

Hmm, doesn't seem to work for me.  I did:

# grub2-mkconfig  > /etc/grub2.cfg
# grubby --default-kernel
#

Header is different now than before:

if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

Can you show me the actual before and after diff?

(and by show, I mean "attach")

Created attachment 781667 [details]
grub2.cfg

Created attachment 781668 [details]
grubenv

Note I'm running F19 now...

So, this actually seems to be correct behaviour - we're looking for the saved entry, and none of the stanzas match it, so we're not choosing any of them as the default.  Arguably it would be correct for us to fall back to assuming it's the first entry, since that's what grub2 is going to do.

The question this raises is how you got one string into grubenv and another string into grub.cfg's menuentry.

Well, it appears that /boot/grub2/grubenv has not been updated since install time.  I've been hacking grub2.cfg to be:

if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default=0
fi

To get grubby to work previously.  Perhaps that prevented grub2 from updating grubenv?  I'll try rebooting and see if that clears it up.

I agree that it may be reasonable to output the first kernel if that is what grub2 will boot.  Or output an error.

Package grubby-8.27-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grubby-8.27-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13999/grubby-8.27-1.fc19
then log in and leave karma (feedback).

So simply rebooting didn't seem to help.  I ran:

# grub2-set-default 2

Which did:

# cat /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=2
# grubby --default-kernel
#

So it looks like grubby no longer handles numbers?  Works with names:

# grub2-set-default 'Fedora, with Linux 3.9.9-302.fc19.x86_64'
# grubby --default-kernel
/boot/vmlinuz-3.9.9-302.fc19.x86_64

grubby-8.28-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grubby-8.28-1.fc19

grubby-8.28-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.