Bug 742720 - yum update with new kernel strips white space from /etc/default/grub GRUB_DEFAULT value
yum update with new kernel strips white space from /etc/default/grub GRUB_DEF...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
16
x86_64 All
unspecified Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Patch
: 756317 761118 783777 808821 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-01 23:02 EDT by mrdvt92
Modified: 2012-06-02 19:57 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-02 19:57:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
preserve trailing(!) indentation when splitting line elements (1.99 KB, patch)
2011-10-24 19:08 EDT, Mads Kiilerich
no flags Details | Diff

  None (edit)
Description mrdvt92 2011-10-01 23:02:58 EDT
Description of problem: 
yum update with new kernel strips white space from /etc/default/grub GRUB_DEFAULT value.  I have the value set to "Windows 7 (loader) (on /dev/sda1)" but the /boot/grub2/grub.cfg file that was created after kernel install is missing two spaces.

Version-Release number of selected component (if applicable):

# rpm -q --whatprovides /etc/default/grub
grub2-1.99-6.fc16.x86_64

# yum history info 69
Install     kernel-3.1.0-0.rc8.git0.0.fc16.x86_64               @updates-testing

How reproducible:

Steps to Reproduce:
1. # grub2-mkconfig -o /boot/grub2/grub.cfg
2. # reboot to older kernel
3. # yum reinstall kernel-3.1.0-0.rc8.git0.0.fc16.x86_64
4. # verify set default value
  
Actual results:

# grep default= /boot/grub2/grub.cfg  
set default="Windows7(loader) (on /dev/sda1)"

grub2-mkconfig | diff - /boot/grub2/grub.cfg

12c12
< set default="Windows 7 (loader) (on /dev/sda1)"
---
> set default="Windows7(loader) (on /dev/sda1)"


Expected results:

There "should" be no diff as the string is quoted.  The default value does not work without the spaces and boots first line in grub2.

Additional info:

grub2-mkconfig gets it right.
Comment 1 Mads Kiilerich 2011-10-24 11:23:51 EDT
The problem must be that grubby strips the spaces. Changing component.
Comment 2 Mads Kiilerich 2011-10-24 19:08:02 EDT
Created attachment 529974 [details]
preserve trailing(!) indentation when splitting line elements
Comment 3 mrdvt92 2011-11-17 22:47:22 EST
I just updated to kernel-3.1.1-1.fc16.x86_64 and the bug is a little bit different but still not fixed.

$ sudo grep Windows /etc/grub2.cfg
set default="Windows7 (loader) (on /dev/sda1)"
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {

Now there is only one missing space (between the "Windows" and the "7") instead of the two.

What I don't get is why does grub2-mkconfig get it correct but the kernel rpm install does not.  I think they should both be using the same lib but I guess they are not.

$ sudo grub2-mkconfig 2>/dev/null|grep Windows
set default="Windows 7 (loader) (on /dev/sda1)"
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {


Thanks,
Mike

mrdvt92
Comment 4 Mads Kiilerich 2011-11-18 08:07:22 EST
(In reply to comment #3)
> What I don't get is why does grub2-mkconfig get it correct but the kernel rpm
> install does not.  I think they should both be using the same lib but I guess
> they are not.

Like it or not, optimal or not: grub2-mkconfig is currently only run by anaconda or manually by the sys admin, and the "daily" maintenance is done by grubby which try to preserve all manual changes made to grub.cfg.
Comment 5 Mads Kiilerich 2011-11-25 11:03:03 EST
*** Bug 756317 has been marked as a duplicate of this bug. ***
Comment 6 mrdvt92 2011-11-25 21:32:36 EST
I just installed kernel-3.1.2-1.fc16.x86_64 and on install the default was missing two spaces.

set default="Windows7(loader) (on /dev/sda1)"

When I uninstalled the old kernel

$ sudo yum erase kernel-3.1.1-2.fc16.x86_64

I was left with only one missing space... 

set default="Windows7 (loader) (on /dev/sda1)"

It's interesting that install and erase show different symptoms.

Thanks,
Mike

mrdvt92
Comment 7 Mads Kiilerich 2011-11-25 21:42:40 EST
Kernel installation will invoke grubby twice. I guess it loses one space on each invocation.
Comment 8 Marc Ruiz 2011-11-28 14:45:51 EST
Im having the same problem. I had correctly set my Windows XP as default prior to last kernel update, I have my /etc/default/grub as:

GRUB_DEFAULT="Microsoft Windows XP Professional (on /dev/sda1)"

After upgrading kernel to 3.1.2.1 it stopped booting Windows as default,  after looking a look into /etc/default/grub it showed OK, so i came to look at grub.cfg and there it was showing wrong:

set default="MicrosoftWindowsXPProfessional (on /dev/sda1)"

Tried running grub2-mkconfig but still showing the same:

set default="MicrosoftWindowsXPProfessional (on /dev/sda1)"

Had to change grub.cfg manually to get it working, but it will stop again on next kerne update.
Comment 9 Mads Kiilerich 2011-11-28 14:54:20 EST
(In reply to comment #8)
> Tried running grub2-mkconfig but still showing the same:
> 
> set default="MicrosoftWindowsXPProfessional (on /dev/sda1)"

That would be _very_ strange. Can you reproduce that? How do you run grub2-mkconfig?
Comment 10 Marc Ruiz 2011-11-28 15:04:34 EST
sorry, my fault. I was running only grub2-mkconfig thinking it would update automatically the correct file /boot/grub2/grub.cfg . After running grub2-mkconfig -o /boot/grub2/grub.cfg it was correctly set.
Comment 11 Mads Kiilerich 2011-11-28 15:06:56 EST
Ok.

The workaround for now would be to edit to title of entry to something without spaces.

Most users has Fedora as default and will thus just have default=0.
Comment 12 Sandro Mathys 2011-11-28 16:07:16 EST
That may be valid for the cases of titles missing spaces. In my case (which was marked as a duplicate in comment #5), the superuser is called user1user2 instead of having two superusers: user1 and user2. Therefore grub2 can't be unlocked like that anymore until grub.cfg is manually fixed. Of course I notices this when my system wasn't bootable anymore without adding a specific runlevel/target ;)
Comment 13 Mads Kiilerich 2011-12-08 14:25:12 EST
*** Bug 761118 has been marked as a duplicate of this bug. ***
Comment 14 Brian Lane 2011-12-12 17:34:45 EST
I'm not sure about this patch, it is using i+1 w/o checking any bounds. I'd also like to see a new test for the spaces issue instead of modifying an existing test.
Comment 15 Mads Kiilerich 2011-12-12 20:00:18 EST
Yes, the patch literally introduces an "[i + 1]", but actually it just moves an assignment made after "i++" to be made before it. It is no more and no less error prone than before.

I did however at one point convince myself that the shuffling done in the surrounding for loop ensures that is secure.

Making grubby pretty is outside the scope of this (and any other) patch.


I agree that modifying a potentially important part of an existing test could remove some import test. Adding a completely new test just for this purpose do however also seem wrong. I think the best compromise is to add another kind of line such as 'set superusers="foo bar  baz"' as described on bug 756317.


An updated patch (and a test cleanup) is available on https://bitbucket.org/kiilerix/grubby/ .
Comment 16 Jeff Guerdat 2012-02-10 09:26:35 EST
Not sure why this persists.  Even F17 grubby shows no action.  Comment 11 is off-base since it doesn't matter who uses what.
Comment 17 Sergio Monteiro Basto 2012-03-20 22:02:20 EDT
Hi, I think we have more 2 duplicated bug #744174 and bug #783777 ,
so removing spaces, of sections workaround the problem ? I'm trying that now .
Comment 18 Robert Scheck 2012-03-21 05:33:28 EDT
*** Bug 783777 has been marked as a duplicate of this bug. ***
Comment 19 Sergio Monteiro Basto 2012-03-30 12:09:56 EDT
even without spaces , default boot to windows doesn't work
Comment 20 Mads Kiilerich 2012-03-30 13:06:43 EDT
(In reply to comment #19)
Sergio, that would be a completely different issue. Please find an existing report of that or file a new issue.
Comment 21 Elbin Pallimalil 2012-04-08 22:58:43 EDT
*** Bug 808821 has been marked as a duplicate of this bug. ***
Comment 22 Sergio Monteiro Basto 2012-04-16 20:52:22 EDT
(In reply to comment #21)
> *** Bug 808821 has been marked as a duplicate of this bug. ***

this report is duplicated of #74417 which is saying "default boot to windows doesn't work", not a problem of spaces .
Comment 23 Elbin Pallimalil 2012-04-16 21:11:46 EDT
(In reply to comment #22)
> (In reply to comment #21)
> > *** Bug 808821 has been marked as a duplicate of this bug. ***
> 
> this report is duplicated of #74417 which is saying "default boot to windows
> doesn't work", not a problem of spaces .

Cause of #808821 is the same as what is described here. #744174 talks about grub 1.
Comment 24 Sergio Monteiro Basto 2012-05-09 21:04:33 EDT
hi
FYI 
 bug 820454 opened , "default boot to windows doesn't work", not a problem of spaces  .
Comment 25 Fedora Update System 2012-05-31 12:32:37 EDT
grubby-8.12-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17
Comment 26 Fedora Update System 2012-06-01 13:03:38 EDT
Package grubby-8.12-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grubby-8.12-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8708/grubby-8.12-1.fc17
then log in and leave karma (feedback).
Comment 27 Fedora Update System 2012-06-02 19:57:08 EDT
grubby-8.12-1.fc17 has been pushed to the Fedora 17 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.