update-grub fails when default is "saved" (expr: non-numeric argument)

[Johannes Rohr]

Binary package hint: grub

summary says it all.

lala@hardy:~$ LANG=C sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
expr: non-numeric argument
lala@hardy:~$

same with sh -x:

+ [ /boot/vmlinuz-2.6.24-5-generic != ]
+ [ -1 -gt 0 ]
+ newerKernels= /boot/vmlinuz-2.6.24-8-generic /boot/vmlinuz-2.6.24-7-generic
+ [ /boot/vmlinuz-2.6.24-5-generic != ]
+ newerKernels= /boot/vmlinuz-2.6.24-8-generic /boot/vmlinuz-2.6.24-7-generic /boot/vmlinuz-2.6.24-5-generic
+ sortedKernels= /boot/vmlinuz-2.6.24-8-generic /boot/vmlinuz-2.6.24-7-generic /boot/vmlinuz-2.6.24-5-generic
+ test -f /boot/vmlinuz.old
+ test -f /boot/vmlinuz
+ use_grub_set_default=false
+ test true = true
+ sed -ne s/^[[:blank:]]*default[[:blank:]]*\(.*\).*/\1/p /boot/grub/menu.lst
+ defaultEntryNumber=saved
+ [ saved = saved ]
+ sed q /boot/grub/default
+ defaultEntryNumber=default
+ use_grub_set_default=true
+ test -n default
+ expr default + 1
expr: non-numeric argument
+ defaultEntryNumberPlusOne=
jr@hardy:~$

[Steve Langasek (vorlon)]

Hi Johannes,

Can you please send the contents of /boot/grub/default on your system?

It appears from this output that the first line of this file is 'default'. It makes no sense to declare a default of "default"; perhaps seeing the full contents of the file, we can figure out how it got that way.

Hmm, apparently 'grub-set-default default' is a supported command - but I wonder what it's supposed to mean? Did you run this command at some point?

[Johannes Rohr (jorohr)]

Am Donnerstag, den 21.02.2008, 21:05 +0000 schrieb Steve Langasek:
> Hi Johannes,
>
> Can you please send the contents of /boot/grub/default on your system?
>
> It appears from this output that the first line of this file is
> 'default'. It makes no sense to declare a default of "default"; perhaps
> seeing the full contents of the file, we can figure out how it got that
> way.

I wasn't aware of the existence of this file, which is why I haven't
touched it. At least not manually. Neither have I run
"grub-update-default"

I have used startupmanager, thought, to modify the grub configuration.
Since startupmanager is advertised as having been developed specially
for Ubuntu, I assumed that it would do the right thing.

Thanks,

Johannes

default
#
#
#
#
#
#
#
#
#
#
# WARNING: If you want to edit this file directly, do not remove any line
# from this file, including this warning. Using `grub-set-default\' is
# strongly recommended.

[Steve Langasek (vorlon)]

I've had a look at startupmanager, and don't see anything in there that would have created a /boot/grub/default of this sort. If you also didn't create it by hand, I don't know how this file came to be. I would suggest resetting it with 'grub-set-default 0' to work around the problem you're having.

Still, 'grub-set-default default' is part of the documented interface for this command, so update-grub should be able to handle this case. Confirming this bug.

[Dern (nico-deranter)]

FYI: This problem occurs when updatedefaultentry in /boot/grub/menu.lst is set to true. Setting to false again allows update-grub to run again.

[Ahmed khan (khanmk1)]

This problem occurs when updatedefaultentry in /boot/grub/menu.lst is set to false. Setting to true again allows update-grub to run again.
Then "sudo dpkg --configure -a"
Solve the problem.

[Ramgs (ramiro-gonzalez-s)]

In my case the entry was commented:

# updatedefaultentry=true

Uncommenting and setting to false, solved the problem.

updatedefaultentry=false

Then "sudo dpkg --configure -a" and is done.

[Removed by request (removed1653457)]

i did it, wait & see

2010/2/21 Ramgs <email address hidden>

> In my case the entry was commented:
>
> # updatedefaultentry=true
>
> Uncommenting and setting to false, solved the problem.
>
> updatedefaultentry=false
>
> Then "sudo dpkg --configure -a" and is done.
>
> --
> update-grub fails when default is "saved"
> https://bugs.launchpad.net/bugs/193439
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
73

Thierry de F4CXF

[Kejope (kejope)]

I had this same issue as I was trying to perform regular updates in Jaunty.

Based on the comments here, I changed one line from:
# updatedefaultentry=true
to:
# updatedefaultentry=false

The update succeeded this time. I restored the original line afterwards.

It seems to be related to certain entries related to a 160GB IDE hard disk that insists on being the boot drive if it is connected. My other hard drives are SATA. I have attached the output from fdisk -l.

All of my Linux partitions are reiserfs, except for /dev/sdc5, which is ext2.
sda = SATA
sdb = SATA
sdc = IDE

The entries in menu.lst:

 boot hard drive that I had removed. I think, but can not guarantee, that this is the first kernel update since I removed the hard disk permanently. I had used grub to install to both hard drives, knowing that I would be experimenting with the removal of the one, but still wanted the computer to boot with only the first hard drive connected.

I am willing to help test if anyone has suggestions.

[Kejope (kejope)]

So VERY sorry for that! I was in the middle of some further experiments and did not mean to post yet. I don't see any way to edit my post!

My entire paragraph about the hard drive being removed is false. I had meant to delete that paragraph before posting. I realized that the hard disk is currently connected and so therefore its absence was not the cause at all.

I had told update-grub to install the package maintainer's version of menu.lst, then saw that two entries were missing that I wanted to keep. I copied them back into menu.lst. I ran update-grub again and got the error. My test was to reinsert/remove these two entries:

The entries in menu.lst:
title Mac OS X 02 1,4 v9
root (hd1,4)
kernel /boot/boot_mac
boot

title Mac OS X 01 1,4 ch
root (hd1,4)
kernel /boot/boot_ch
boot

The first couple of times I did that, I got no error from running /sbin/update-grub while the entries were absent, but got the error when they were present.

After several more tests, I seem to have come to a dead end. I can no longer reproduce the toggling of working/not-working that I was able to do a few minutes ago. Now, I do not get the error at all. I don't know what has changed.

Yay!(?)

I am willing to help test if anyone has suggestions.