Bug 768106 - grubby does not support grub2 set default="${saved_entry}" and replaces with "0"
grubby does not support grub2 set default="${saved_entry}" and replaces with "0"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
19
All All
unspecified Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 785378 820454 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-15 14:01 EST by shaftanista
Modified: 2013-08-05 20:18 EDT (History)
25 users (show)

See Also:
Fixed In Version: grubby-8.28-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-05 20:18:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description shaftanista 2011-12-15 14:01:41 EST
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.
Comment 1 Mads Kiilerich 2012-04-09 16:00:30 EDT
*** Bug 785378 has been marked as a duplicate of this bug. ***
Comment 2 Joachim Jaeckel 2012-04-10 11:04:28 EDT
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.
Comment 3 nicofo 2012-04-14 12:01:58 EDT
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 ?
Comment 4 Mads Kiilerich 2012-04-14 12:14:41 EDT
(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 ;-)
Comment 5 Jack 2012-04-18 05:26:51 EDT
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.
Comment 6 shaftanista 2012-04-18 06:12:50 EDT
(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.
Comment 7 Jack 2012-04-18 11:14:05 EDT
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.
Comment 8 Thomas Müller 2012-04-18 12:16:16 EDT
(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.
Comment 9 Mads Kiilerich 2012-04-18 12:37:43 EDT
(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?
Comment 10 Jack 2012-04-18 16:05:54 EDT
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.
Comment 11 Mads Kiilerich 2012-04-18 16:19:00 EDT
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.
Comment 12 shaftanista 2012-04-18 16:35:02 EDT
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.
Comment 13 Jack 2012-04-19 04:14:10 EDT
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.
Comment 14 Mads Kiilerich 2012-05-14 07:45:06 EDT
*** Bug 820454 has been marked as a duplicate of this bug. ***
Comment 15 Sergio Monteiro Basto 2012-05-31 14:23:26 EDT
FYI finally on F17, on update kernel. 

set default= 
was updated correctly , but works with number and updated from 2 to 3
Comment 16 Mads Kiilerich 2012-05-31 14:40:58 EDT
(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.
Comment 17 Sergio Monteiro Basto 2012-05-31 14:47:14 EDT
(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 .
Comment 18 Mark Chappell 2012-12-07 05:36:02 EST
Bumping the version since this issue is still present
Comment 19 Fedora End Of Life 2013-04-03 13:03:15 EDT
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
Comment 20 Peter Jones 2013-07-30 13:41:00 EDT
Please try the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=5680227 , grubby-8.27-1.fc20, which should fix this issue.
Comment 21 Peter Jones 2013-07-30 14:15:58 EDT
Sorry, going to wind up being http://koji.fedoraproject.org/koji/taskinfo?taskID=5680356 instead.
Comment 22 Fedora Update System 2013-07-31 11:09:21 EDT
grubby-8.27-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grubby-8.27-1.fc19
Comment 23 Orion Poplawski 2013-07-31 11:33:53 EDT
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)'''
Comment 24 Peter Jones 2013-08-01 11:36:26 EDT
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.
Comment 25 Fedora Update System 2013-08-01 23:40:25 EDT
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).
Comment 26 Orion Poplawski 2013-08-02 14:39:11 EDT
Peter - pj1 handles the parens quoting fine for me
Comment 27 Fedora Update System 2013-08-02 15:35:24 EDT
grubby-8.28-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grubby-8.28-1.fc19
Comment 28 Fedora Update System 2013-08-05 20:18:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.