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.
The problem must be that grubby strips the spaces. Changing component.
Created attachment 529974 [details] preserve trailing(!) indentation when splitting line elements
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
(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.
*** Bug 756317 has been marked as a duplicate of this bug. ***
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
Kernel installation will invoke grubby twice. I guess it loses one space on each invocation.
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.
(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?
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.
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.
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 ;)
*** Bug 761118 has been marked as a duplicate of this bug. ***
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.
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/ .
Not sure why this persists. Even F17 grubby shows no action. Comment 11 is off-base since it doesn't matter who uses what.
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 .
*** Bug 783777 has been marked as a duplicate of this bug. ***
even without spaces , default boot to windows doesn't work
(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.
*** Bug 808821 has been marked as a duplicate of this bug. ***
(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 .
(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.
hi FYI bug 820454 opened , "default boot to windows doesn't work", not a problem of spaces .
grubby-8.12-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17
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).
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.