*** Bug 785378 has been marked as a duplicate of this bug. ***

Maybe partial workaround:

grubby will honor the option
   UPDATEDEFAULT=no
in /etc/sysconfig/kernel

This prevents booting a new kernel after update. You have to edit then entry 'set default="n"' in /boot/grub2/grub.cfg if you want to boot the new kernel.

One question: why does Fedora use grubby ?

Other distributions with grub2 don't use it without problem. Fedora uses it with problems (see this bug and several others (like bug 785379, etc...): the solution is always the same: by-pass grubby and use grub2-mkconfig instead).

=> Why not only use grub2-mkconfig ?

(In reply to comment #3)
> One question: why does Fedora use grubby ?

Because grubby (the package) provides an abstraction of which bootloader(s) is used, and for some boot loaders the 'patch the boot loader configuration file' approach used by grubby (the binary) makes a lot of sense.

Some users prefer to edit the boot loader configuration file manually. They will complain loudly if Fedora starts overwriting their changes when packages are installed.

You can try start hacking new-kernel-pkg and come up with a patch that makes it possible to opt in to invoking grub2-mkconfig instead of grubby.

That is however all off topic for the issue discussed here ;-)

When I perform a kernel update (nearly weekly), I do not expect that even though I have edited /etc/default/grub to read as follows:

GRUB_DEFAULT="Windows 7 (loader) (on /dev/sda1)"

that grubby will decide to make the new Linux kernel the default boot target. 

Since grubby fails to correctly 'understand' /etc/default/grub when (re)creating /boot/grub2/grub.cfg grubby is at fault, and so has a bug, because /etc/default/grub is the path used by default (on Fedora) for grub2-mkconfig

Reading the documentation for grubby, it seems that there is a command-line option to display the current default kernel (--default-kernel).  This appears to not work correctly, since it reports a default which is not my current default. Had this worked correctly, it would seem a trivial matter to discover the correct default, and reset it.

(In reply to comment #5)
grubby does not use /etc/default/grub at all, and it is by design. It operates directly on /boot/grub2/grub.cfg.

Try using the tip from comment #2, it may solve your problem.

Well, that's just stupid on many levels.

Firstly, the fact that any tool would choose to operate directly upon a file that is used by a completely separate application (not to mention vital)- which also provides its own tools for generating that file - is just dumb.  grubby thus has then an implicit version dependency upon grub, while not being a part of the grub project (or if it is, I can't tell).

Secondly, the use of /etc/sysconfig/kernel.  For starters, there is no obvious link between a utility named grubby and /etc/sysconfig/kernel. Furthermore, /etc/sysconfig/kernel is from what I can tell, completely non-documented, nor discussed: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-The_sysconfig_Directory.html

Also, the whole usage of /etc/sysconfig directory is supposed to be being phased out, since it's a fairly senseless, redundant directory structure.

So, grubby's by-design behavior is a design fault, and should be corrected.

(In reply to comment #4)
> (In reply to comment #3)
> > One question: why does Fedora use grubby ?
> 
> Because grubby (the package) provides an abstraction of which bootloader(s) is
> used, and for some boot loaders the 'patch the boot loader configuration file'
> approach used by grubby (the binary) makes a lot of sense.
> 
> Some users prefer to edit the boot loader configuration file manually. They
> will complain loudly if Fedora starts overwriting their changes when packages
> are installed.

So instead of overwriting manual changes to the bootloader configuration (which anyway is discouraged by a big fat warning at the beginning of the file) grubby destroys properly setup configurations which have been done as documented...
That doesn't really make a lot of sense in my opinion.

All in all it's currently impossible to use the "boot whatever I selected the last time"-feature of grub2, which is kind of nice in multi-boot environments. Even setting UPDATEDEFAULT=no does not help here as grubby always forces a 'set default="0"' line into the configuration.

(In reply to comment #8)

Yes, bugs in software often cause bogus behaviour. Grubby is no exception to that. Is that the point you are trying to make?

I think the point is not grubby's buggy behavior. The point is grubby is not fit for purpose because it's designed-in behavior is wrong headed. Its behavior is so wrong it should not be a part of the kernel upgrade process.

grub2-mkconfig is a huge error-prone monster too and not necessarily something I would like to run in kernel %post.

I doubt a change to grub2-mkconfig is going to change overnight, so as suggested in comment 4: Try to come up with a patch to new-kernel-pkg that reads /etc/sysconfig/kernel and optionally runs grub2-mkconfig instead of grubby. It is shell script and much more readable than anything in grub2.

That's certainly a good idea - Linux was always about customization, so being able to choose the way you configure your bootloader on kernel update is a right thing to do.

But also, as I suggested in the original post, implementing a "don't touch it if you don't understand it" semantic for default entry in grubby itself would also not hurt and basically solve the problem.

So, the proposal is to change this:


    if [ -n "$cfgGrub2" ]; then
        [ -n "$verbose" ] && echo "adding $version to $grub2Config"

        if [ -n "$banner" ]; then
            title="$banner ($version)"
        elif [ -f /etc/redhat-release ]; then
            title="$(sed 's/ release.*$//' < /etc/redhat-release) ($version)"
        else
            title="Red Hat Linux ($version)"
        fi
=>      $grubby --grub2 -c $grub2Config \
            --add-kernel=$bootPrefix/$kernelName-$version \
            $INITRD --copy-default $makedefault --title "$title" \
            ${mbkernel:+--add-multiboot="$mbkernel"} \
            ${mbargs:+--mbargs="$mbargs"} \
            --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title"
    else

so that the call to 
         $grubby --grub2.......

is replaced with a call to

         grub2-mkconfig -o $grub2Config

??

That certainly seems to make more sense to me.  This way we let the grub tool write it's own grub.cfg file, which then honors its input /etc/default/grub.  That relieves grubby from having to understand grub2's cfg file.

*** Bug 820454 has been marked as a duplicate of this bug. ***

FYI finally on F17, on update kernel. 

set default= 
was updated correctly , but works with number and updated from 2 to 3

(In reply to comment #15)
> set default= 
> was updated correctly , but works with number and updated from 2 to 3

???

The point made here in this bug report is that "works correctly" means that grubby should preserve ${saved_entry} and not use numbers at all.

(In reply to comment #16)
> (In reply to comment #15)
> > set default= 
> > was updated correctly , but works with number and updated from 2 to 3
> 
> ???
> 
> The point made here in this bug report is that "works correctly" means that
> grubby should preserve ${saved_entry} and not use numbers at all.

well at least , preserve the boot entry , which one step .

Bumping the version since this issue is still present

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

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

I'm not sure if this is an effect of 8.27 or not (I suspect it is), but installing a new kernel gives me:

  Installing : kernel-3.10.3-300.fc19.x86_64                                              39/100 
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `grub2-editenv /boot/grub2/grubenv set 'saved_entry='Fedora (3.10.3-300.fc19.x86_64) 19 (Schrödinger’s Cat)'''

Gah. That's what I get for testing on rawhide but not F19.  Okay, so I need to handle escaping that thing then.

Thanks for the testing, I'll do another update soon.

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

Peter - pj1 handles the parens quoting fine for me

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.