grubby does not support saved_default semantics in grub2, resetting the default entry to "0" each time it is run. It makes the saved default semantics disappear in Fedora each time the kernel is updated (can be fixed by manually editing grub2.cfg or running grub2-mkconfig). Version-Release number of selected component (if applicable): grubby-8.3-2.fc16.x86_64 Steps to Reproduce: 1. Edit /boot/grub2/grub.cfg to use 'set default="${saved_entry}"' or generate it with grub2-mkconfig with GRUB_DEFAULT set to "saved" in /etc/default/grub 2. Run grubby, without using --make-default, for example: grubby --grub2 -c /boot/grub2/grub.cfg --add-kernel=/boot/some-fancy-vmlinuz --initrd=/boot/some-cute-initramf --copy-default --title "Some Cool Title" --args='root=/dev/sda1' 3. Examine /boot/grub2/grub.cfg Actual results: The default entry line changed to 'set default="0"' Expected results: The default entry stays as 'set default="${saved_entry}"' Additional info: As can be seen in grubby.c:211, grubby is programmed so that it "thinks" it's impossible to use saved default in grub2. Furthermore, readConfig() is currently written so that it can recognize and store saved default only if the value of the default entry is supposed to be exactly "saved" (grubby.c:1017 and grubby.c:1062). In my opinion, the best solution would be to implement a "if we can't understand the current default, it's probably saved default" semantic, in other words "don't touch it if you don't understand it". grubby would treat any default line it cannot properly parse as saved default, and replicate it as it were on write. Or... just revert to using grub2-mkconfig for grub2. What's the reason behind not using it? It works, is well known and widely used in other distributions, and pretty configurable.
*** 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.