update-grub not updating menu.lst

Here is my menu.lst

Hi Jamie,

Please also provide the contents of /var/lib/ucf/cache/\:var\:run\:grub\:menu.lst .

What is your DEBIAN_FRONTEND set to when you invoke update-grub?

$ echo "get debconf/frontend" | debconf-communicate
0 Dialog

Here is an strace, though nothing jumped out at me.

 $ echo "get debconf/frontend" | debconf-communicate
 0 Dialog

This is not DEBIAN_FRONTEND; I'm looking for the value of the DEBIAN_FRONTEND environment variable here, which overrides whatever frontend setting is stored in debconf itself.

The expected behavior is that when you run update-grub (as part of a package install or otherwise) and there are local changes in your menu.lst relative to the last auto-generated menu.lst, you get a debconf prompt asking you how to resolve this conflict.

Of course, once this conflict has been resolved for a given iteration of the menu.lst, you won't be asked again until the proposed menu.lst settings change. So if you had DEBIAN_FRONTEND=noninteractive set when you *last* upgraded, running update-grub again will not give you a new prompt. To force the prompt to be shown, you can adjust one of the settings in your kopt_2_6 line and re-run update-grub.

I am not explicitly setting DEBIAN_FRONTEND and I have never set that myself. I did change menu.lst at one point (playing with splash and quiet) and do remember getting prompted by grub. I said to keep the currently installed version:
$ echo "get grub/update_grub_changeprompt_threeway" | debconf-communicate
0 keep_current

I thought this meant don't change things like defoptions, altoptions, etc and didn't think it would have anything to do with my AUTOMAGIC kernels.

I also now know why the strace didn't do anything-- I didn't realize update-grub was a shell script! I have attached update-grub modified with '#!/bin/bash -x' output.

I am in the same boat. Like Jamie, I said not to alter menu.lst because I had removed "splash" from the default options.

I ran into the same problem. That is, update-grub did not update menu.lst because I answered "keep old version"
Note that with "Keep old version", update-grub will not install new kernel images into menu.lst

The wording seems wrong, since I interpreted "Install package maintainers version" to mean that all the changes I have done to defoptions will be thrown out.

Ditto. The wording of the prompt is totally unhelpful. It asks something like "What would you like to do with menu.lst", to which my natural response is "I haven't a clue, please tell me what you're trying to do with it!"

Since I didn't understand the question and couldn't find an answer online in the first thirty seconds of googling, I opted to stick with the default, which apparently was completely wrong. Please can we have this fixed so that the wording explains what will actually happen, and selecting the default option means that my automagic kernels are updated but my changed settings outside the automagic section aren't touched?

I was having this problem too. I just uninstalled all the old kernel items via synaptic. Anything with linux 2.6.22-14 should be able to be removed. I was then prompted again whether I would like to keep my current menu.lst. This time I said to use the package maintainer's version and menu.lst was fixed. I was booted into my 2.6.24-16 manually already but I don't think that'd make a difference.

I have to agree with jfjellstad and bugmenot, the wording is pretty confusing. I assumed that what came up with as default was the prior action, that it would update menu.lst with the new kernels at the top of the AUTOMAGIC section. I think better wording for "Install package maintainers version" would be "Add new kernels to menu.lst" if that is indeed all it does. "package maintainers version" makes it sound like it's going to blow up any customizations you've done to it, obviously not what any of us really want.

Can confirm this. The same issue: aptitude installed the newer kernels, I failed to allow the postinstall script to overwrite grub.lst. I thought it wants to change some default values, that I set to my preferences, and the boot lines are going to be updated anyway, later, when update-grub is called by postinstall.

But update-grub does not rewrite the appropriate lines, even as it prints out correct "Found kernel: " lines. It does not updates them even when called later manually.

Please set Importance to critical, as this is a serious issue: if someone runs into this, and deinstalls older kernels, he/she will be unable to boot his/her system.

Another big problem is:

If I start grub-update and choose the menu.lst version which is provided by the packager, my menu.lst file grows bigger and bigger everytime I run grub-update.

That mustn't happen - choosing menu.lst version from packager should create a clean menu.lst file - otherwise people cannot recreate a clean file if they have changed some values!

I attach my menu.lst file with lots (!) of multiple entries (I had to compress it because it is over 2 MByte big!)

I'm still experiencing this problem in Intrepid.

Me too.. Is there any workaround?

I tried re-installing the kernel, but still update-grub refuses to modify menu.lst. Also tried to install and use startupmanager; this hangs on close.

/var/lib/ucf/cache/\:var\:run\:grub\:menu.lst does show the kernels I expect to see in the normal menu.lst.

I have nothing set for DEBIAN_FRONTEND.

Have located my problem:

NEVER put anything manually into the

#### BEGIN AUTOMAGIC KERNELS LIST

section. Otherwise menu.lst will grow bigger and bigger!

Put menu additions below the ## End default options ## section

Thanks for this . Will try as soon as possible.

--
Francis

On Mon, Nov 24, 2008 at 6:42 PM, felix.rommel <email address hidden> wrote:

> Have located my problem:
>
> NEVER put anything manually into the
>
> #### BEGIN AUTOMAGIC KERNELS LIST
>
> section. Otherwise menu.lst will grow bigger and bigger!
>
> Put menu additions below the ## End default options ## section
>
> --
> update-grub not updating menu.lst
> https://bugs.launchpad.net/bugs/202009
> You received this bug notification because you are a direct subscriber
> of the bug.
>

just got bitten by this myself. I do think that something leaving an inexperienced user unable to boot the system is indeed critical. Marking as such, please adjust if you feel this is necessary.

for this bug to leave your system unbootable, you must:
- manually edit the list of boot stanzas in the "automagic" section of menu.lst
- install a new kernel and choose the "safe" default when asked what to do about menu.lst
- manually uninstall your existing kernel.

Downgrading the bug importance.

As this can cause users to run older kernels, in particular missing security fixes, I'd argue that it's fairly important.

I think I have a similar issue. I also removed the splash option from the kernel, and I was also prompted to keep my modified version of menu.lst.

However, I remembered what I had done and choose to use the maintainer's version. Now, menu.lst does not reflect what is presented at boot time. It doesn't matter what I do to menu.lst, the new kernel does not show as an option. menu.lst shows 2.6.27-11 as the newest kernel, but the boot menu shows 2.6.27-9 as the newest available kernel. Also, the non-recovery options all have the splash option, but there is no splash option at boot time. No matter what I do to menu.lst, it is not reflected at boot time.

There are no other .lst files in /boot/grub/. I am going to try and remove the other kernels. I just didn't want to make my machine unbootable.

I removed linux-image-2.6.24-22-generic and got the same prompt about menu.lst. I chose to keep the maintainers version. I rebooted with the same results. In fact, I was able to boot to the 2.6.24-22 kernel even though I removed the image.

I tried running sudo update-grub and sudo dpkg-reconfigure linux-image-2.6.27-11-generic to no avail. menu.lst looks good, but the grub menu at boot time is still the old menu.

I am curious as to where menu.lst is being read from or cached. In my experience, if menu.lst was changed, it would show on the next reboot with no other steps required.

On Thu, Jan 29, 2009 at 05:36:27AM -0000, JacobSteelsmith wrote:
> I removed linux-image-2.6.24-22-generic and got the same prompt about
> menu.lst. I chose to keep the maintainers version. I rebooted with the
> same results. In fact, I was able to boot to the 2.6.24-22 kernel even
> though I removed the image.

I'm pretty sure you're seeing a different bug, then. It sounds like either
your /boot partition is not mounted, or the instance of grub being used to
boot is pointing at a different installation of Ubuntu.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thanks for the reply. I run only one operating system on this machine and I do not have a separate boot partition:

jacob@jakes-desktop:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 228G 161G 56G 75% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
varrun 2.0G 340K 2.0G 1% /var/run
varlock 2.0G 0 2.0G 0% /var/lock
udev 2.0G 2.8M 2.0G 1% /dev
tmpfs 2.0G 12K 2.0G 1% /dev/shm
lrm 2.0G 2.4M 2.0G 1% /lib/modules/2.6.27-9-generic/volatile

I am using software raid in a raid 1 configuration using mdadm.

On Thu, Jan 29, 2009 at 06:01:17AM -0000, JacobSteelsmith wrote:
> Thanks for the reply. I run only one operating system on this machine
> and I do not have a separate boot partition:

> jacob@jakes-desktop:~$ df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/md0 228G 161G 56G 75% /
> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
> varrun 2.0G 340K 2.0G 1% /var/run
> varlock 2.0G 0 2.0G 0% /var/lock
> udev 2.0G 2.8M 2.0G 1% /dev
> tmpfs 2.0G 12K 2.0G 1% /dev/shm
> lrm 2.0G 2.4M 2.0G 1% /lib/modules/2.6.27-9-generic/volatile

> I am using software raid in a raid 1 configuration using mdadm.

Well, that shows that you don't have a separate /boot partition *mounted*,
but that doesn't mean you don't have one somewhere on your hard disk that's
being used instead. Are there no other partitions on your physical hard
disks besides the ones used for /dev/md0?

Also, is there a chance that your RAID array is running in degraded mode for
some reason, preventing the copy of /boot on the first drive from being
updated when you make changes to the system? (cat /proc/mdstat)

But as I said, this is unrelated to the bug you're following up to - this
question would be better dealt with in the Ubuntu forums.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thanks again Steve. I posted in the forum at: http://ubuntuforums.org/showthread.php?p=6638834#post6638834

I have three disks with two partitions each. Two disks are part of the raid 1 array and the third disk is a spare. One partition is mounted on root and the second is the swap. I checked the array's health and it's fine.

Well , I got the same issue.
I backed up my menu.lst, deleted the original one , ran 'sudo upgrade-grub', answered 'yes' to create the file for me ...
And I've got a full menu.lst with all installed kernels.
I just have to reboot to see if everything is ok ...

My buddy Alex helped me fix this. I had to use Grub to write the new /boot/grub/menu.lst to the MBR.

So:

First, get into grub

jacob@jakes-desktop:~$ grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]

Now look for menu.lst

grub> find /boot/grub/menu.lst
find /boot/grub/menu.lst
 (hd0,0)
 (hd1,0)
 (hd2,0)

Make sure the menu.lst is the one you want.

grub> cat (hd0,0)/boot/grub/menu.lst
cat (hd0,0)/boot/grub/menu.lst
# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.
...

Make sure stage1 is on the same partition you're going to use

### END DEBIAN AUTOMAGIC KERNELS LIST
grub> find /boot/grub/stage1
find /boot/grub/stage1
 (hd0,0)
 (hd1,0)
 (hd2,0)
grub> root (hd0,0)

grub> setup (hd0)

I rebooted and it works fine. Thanks!

After https://bugs.launchpad.net/ubuntu/+source/grub/+bug/202009/comments/29 (just a few messages up) , I'm back and everything works

I have just run into this.
 Now when I ran grub and looked for /boot/grub/menu.lst
I get "error 15: file not found"
I'm a noob but I'd like to figure this thing out

Thanks

Guy M, if you are looking for support on how to get around this (or any other) problem, I suggest the ubuntu forums or Launchpad Answers

http://ubuntuforums.org
https://answers.launchpad.net/ubuntu/+source/grub

Confirmed on jaunty.

$ 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 ...
Found kernel: /boot/vmlinuz-2.6.28.7
Found GRUB 2: /boot/grub/core.img
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

menu.lst:
## ## End Default Options ##

title Ubuntu jaunty (development branch), kernel 2.6.28.7
root (hd0,4)
kernel /boot/vmlinuz-2.6.28.7 root=UUID=9f7087dc-a04b-4d18-869a-93e0e388906a ro splash
initrd /boot/initrd.img-2.6.28.7
quiet

title Ubuntu jaunty (development branch), kernel 2.6.24-22-generic
root (hd0,4)
kernel /boot/vmlinuz-2.6.24-22-generic root=UUID=9f7087dc-a04b-4d18-869a-93e0e388906a ro splash
initrd /boot/initrd.img-2.6.24-22-generic
quiet

title Ubuntu jaunty (development branch), kernel 2.6.24-22-generic (recovery mode)
root (hd0,4)
kernel /boot/vmlinuz-2.6.24-22-generic root=UUID=9f7087dc-a04b-4d18-869a-93e0e388906a ro single
initrd /boot/initrd.img-2.6.24-22-generic

title Ubuntu jaunty (development branch), kernel 2.6.28-10-generic
root (hd0,4)
kernel /boot/vmlinuz-2.6.28-10-generic root=UUID=9f7087dc-a04b-4d18-869a-93e0e388906a ro quiet splash
initrd /boot/initrd.img-2.6.28-10-generic
quiet

title Ubuntu jaunty (development branch), kernel 2.6.28-10-generic (recovery mode)
root (hd0,4)
kernel /boot/vmlinuz-2.6.28-10-generic root=UUID=9f7087dc-a04b-4d18-869a-93e0e388906a ro single
initrd /boot/initrd.img-2.6.28-10-generic

title Chainload into GRUB 2
root (hd0,4)
kernel /boot/grub/core.img

title Ubuntu jaunty (development branch), memtest86+
root (hd0,4)
kernel /boot/memtest86+.bin
quiet

$ apt-cache policy grub
grub:
  Zainstalowana: 0.97-29ubuntu51
  Kandydująca: 0.97-29ubuntu51
  Tabela wersji:
 *** 0.97-29ubuntu51 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Confirmed on jaunty.

$ 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 ...
Found kernel: /boot/vmlinuz-2.6.28-11-generic
Found kernel: /boot/vmlinuz-2.6.27-11-generic
Found kernel: /boot/vmlinuz-2.6.27-9-generic
Found kernel: /boot/vmlinuz-2.6.27-7-generic
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

$ cat menu.lst
# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 3

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)
# hiddenmenu

# Pretty colours
#color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line) and entries protected by the
# command 'lock'
# e.g. password topsecret
# password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title Windows 95/98/NT/2000
# root (hd0,0)
# makeactive
# chainloader +1
#
# title Linux
# root (hd0,1)
# kernel /vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

title Windows Vista Home Basic
root (hd1,0)
makeactive
chainloader +1

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=6a3c223e-3d28-4e9e-825e-fb45134945bf ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=6a3c223e-3d28-4e9e-825e-fb45134945bf

## should update-grub create alternative automagic boot options
## e.g. alternative=true
## alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
## lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defo...

This bug affects me, too:

chris@lotus:~$ date
Mo 11. Mai 13:29:05 CEST 2009
chris@lotus:~$ 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 ...
Found kernel: /vmlinuz-2.6.28-11-generic
Found kernel: /vmlinuz-2.6.27-9-generic
Found kernel: /vmlinuz-2.6.24-21-generic
Found kernel: /memtest86+.bin
Updating /boot/grub/menu.lst ... done

chris@lotus:~$ date
Mo 11. Mai 13:29:13 CEST 2009
chris@lotus:~$ egrep "(8.10|9.04)" /boot/grub/menu.lst
title Ubuntu 8.10, kernel 2.6.27-9-generic
title Ubuntu 8.10, kernel 2.6.27-9-generic (recovery mode)
title Ubuntu 8.10, kernel 2.6.24-21-generic
title Ubuntu 8.10, kernel 2.6.24-21-generic (recovery mode)
title Ubuntu 8.10, memtest86

+1 on upgrade from 8.10 to 9.04 not updating the menu.lst on amd-64 - worked fine on my i386 upgrade
I manually changed the names for the images referred in the menu.lst
Now the Grub menu displays correctly and boots correct image.
Sudo update-grub did not write correct image names to menu.lst although I ran it - my outputs were similar to previous reports
I came accross this because cpu-frequency-scaling didn't work:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/365798

images in boot:
2.6.28-11-generic
2.6.27-7-generic

Image 2.6.24-x-generic was referred to in menu.lst but did not exist anymore.

I was also bitten by this when upgrading from 8.10 to 9.04. update-grub said that it found the new kernel, but it did not change menu.lst.

The reason was that I had previously modified the 'automagically generated' section of menu.lst (removing the 'splash' option to help diagnose another issue), instead of using the correct method of modifying the structured comment '# defoptions' *above* the automagically generated section and re-running update-grub. Modifying the wrong section got me the effect I wanted on grub some weeks ago, but with the surprise side-effect yesterday.

To reiterate, to modify menu.lst, you must do it in a way that update-grub likes, or update-grub won't work the next time you install a new kernel. You must modify right structured comment, then re-run update-grub, which will apply your change to the part of the file that it 'owns'.

[Suffice to say, putting the update-grub parameters and the live grub parameters in the same file is strongly counter-intuitive -- there should be a separate 'update-grub.param' file, and the generated 'menu.lst' file should clearly state that it was generated by update-grub and that the correct way to change it is to edit update-grub.param and run update-grub.]

That might never happen, given the investment made by so many people in figuring out the current method ;-), but what should really be fixed now is 'update-grub' -- when it detects that someone has hand-modified the 'wrong' part of the file, it should say so *VERY LOUDLY*, instead of appearing to do the right thing but not changing menu.lst at all.

Confirmed on jaunty.

This is a pretty serious problem. I just discovered that I haven't been running the latest kernel since about four releases ago. I don't really think it's fair to blame on the user for editing the wrong part of the file too. On my system the automagic kernels section was so big that when my test editor was positioned over the place in the list of kernels where I wanted to add the new boot option I couldn't even see the header and footer comments which indicated that this was an automatically created section.

The simplest workaround for this problem by the way is just moving the broken menu.lst and then running 'update-grub'. You can then grab the boot entries you want from the old file and put it in the correct place of the new menu.lst (ie above or below the automagic kernels list),

I don't disagree that this is serious, but unfortunately the old
update-grub is such a mess at this point that it's nearly certain that
any attempts to fix problems will make something else worse. We're
replacing the old update-grub system with grub2's entirely rewritten
version in karmic; I have some hope that it won't suffer from this class
of problem ...

Had this problem when I installed the latest kernel in Jaunty. At the end of the install I accepted the default of keeping the existing Grub menu. Big mistake. update-grub would not add the new kernel to the menu.lst. Spent 2 days trying various solutions proposed in forums.

Finally found a simple solution. Remove /boot/grub/menu.lst. "sudo rm /boot/grub/menu.lst" It will then offer to recreate a new menu.lst. Now run "sudo update-grub" Reboot and it will load the new kernel. Confirmed with uname -a
Only odd thing is you will need to hit escape quickly to see the entire boot list, but that's OK as it saves a step and boot is faster. If you have a duel boot and need time to select a different kernel or OS there is probably some way to modify this and set a time out.

Solved my problem.

This bug shows itself at my place if I make any modifications to the automagic generated kernels. After a modification (for example removing the kernel from the title) a subsequent "sudo update-grub" seems to work, but fails to update the kernel list.

Parker's solution (#41) works, but it is also possible to force the recreation of the kernel list by changing an automagic option in menu.lst. After this you will get the option to install the package maintainer's version. This solution keeps all your settings (except the one you changed). (I cannot change updatedefaultentry to true. It gives "expr: non-numeric argument". I don't know what is should do, but do you all people have this?)

parker's 'problem' with the hidden menu is an option in menu.lst called "hiddenmenu". Commenting that out solves his problem.

Same thing after upgrading from Jaunty to Karmic. Update-grub fails to update menu.lst after I chose to keep my version of menu.lst during the upgrade.

Architecture: amd64
DistroRelease: Ubuntu 9.10
Package: grub 0.97-29ubuntu59
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=pl_PL.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-15.52-generic
Uname: Linux 2.6.28-15-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
 (gnome-settings-daemon:5592): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:5633): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:5627): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:5615): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
 (gnome-help:8376): Yelp-WARNING **: Failed to load config file: No such file or directory

azrael@laptop:~$ sudo fdisk -l
[sudo] password for azrael:

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb452b452

   Device Boot Start End Blocks Id System
/dev/sda1 1 1268 10185178+ 7 HPFS/NTFS
/dev/sda2 * 8740 9729 7945560 7 HPFS/NTFS
Partition 2 does not end on cylinder boundary.
/dev/sda3 1269 2573 10482412+ 83 Linux
/dev/sda4 2574 8739 49528395 5 Extended
/dev/sda5 2574 2704 1052226 82 Linux swap / Solaris
/dev/sda6 2705 7803 40957686 83 Linux
/dev/sda7 7804 8739 7518388+ 83 Linux

Partition table entries are not in disk order

I had to edit menu.lst by hand to fix it, yet I'm afraid that I'll have to do it again after each kernel update.

When I had this problem using 'legacy grub' because I didn't accept
'install maintainer's version' I simply removed grub/menu.lst. When I
rebooted it created a new menu.lst with the updated kernels.

Now I'm using grub2 which presents a whole new set of problems.

Good luck,
Paco

Przemysław Kulczycki wrote:
> ** Attachment added: "menu.lst"
> http://launchpadlibrarian.net/34590261/menu.lst
>
>

On Thu, Oct 29, 2009 at 08:44:57AM -0000, Przemysław Kulczycki wrote:
> Same thing after upgrading from Jaunty to Karmic. Update-grub fails to
> update menu.lst after I chose to keep my version of menu.lst during the
> upgrade.

If you chose to keep your version of menu.lst, this is not a "failure".
It's doing what you told it to.

The bug here is that currently, it's very hard to go back and change your
mind after telling update-grub to do this; but you only see this prompt in
the first place because you're working against update-grub by not using its
kernel stanza autogeneration support. If you set your variables where
update-grub looks for them, there's no reason for you to get a conflict at
all.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

2009/10/29 Steve Langasek <email address hidden>:
> On Thu, Oct 29, 2009 at 08:44:57AM -0000, Przemysław Kulczycki wrote:
>> Same thing after upgrading from Jaunty to Karmic. Update-grub fails to
>> update menu.lst after I chose to keep my version of menu.lst during the
>> upgrade.
>
> If you chose to keep your version of menu.lst, this is not a "failure".
> It's doing what you told it to.

Then the wording of the notice in update-manager should be changed.
My expectation was the same as with update-manager offering to replace
ie. /etc/modprobe.d/blacklist.conf
I thought that update-manager will delete my menu.lst completely, and
then I would have to add my Windows entries manually.

> The bug here is that currently, it's very hard to go back and change your
> mind after telling update-grub to do this; but you only see this prompt in
> the first place because you're working against update-grub by not using its
> kernel stanza autogeneration support.  If you set your variables where
> update-grub looks for them, there's no reason for you to get a conflict at
> all.

Will it retain the additional OS entries outside of the automagically
generated list? (Windows)
Or will it erase them?
I wanted to keep them, that's why I chose to retain my old menu.lst -
I expected update-grub to update the kernel list without touching the
additional OSes.

--
## Przemysław Kulczycki >><< Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

Ok It seems to me that this is irrelevant at this point as all new
releases of Ubuntu will use grub2. It's a pain in the ass, but it is
what is. "Make a change and call it progress" All I want a boot loader
to do is load the OS I want and the latest kernels and then leave me
alone. But the developers are doing this for free so who am I to complain!

Steve Langasek wrote:
> On Thu, Oct 29, 2009 at 08:44:57AM -0000, Przemysław Kulczycki wrote:
>
>> Same thing after upgrading from Jaunty to Karmic. Update-grub fails to
>> update menu.lst after I chose to keep my version of menu.lst during the
>> upgrade.
>>
>
> If you chose to keep your version of menu.lst, this is not a "failure".
> It's doing what you told it to.
>
> The bug here is that currently, it's very hard to go back and change your
> mind after telling update-grub to do this; but you only see this prompt in
> the first place because you're working against update-grub by not using its
> kernel stanza autogeneration support. If you set your variables where
> update-grub looks for them, there's no reason for you to get a conflict at
> all.
>
>

It's still relevant because Grub2 is not installed automatically on
upgrade from Jaunty.

2009/10/29 parker <email address hidden>:
> Ok It seems to me that this is irrelevant at this point as all new
> releases of Ubuntu will use grub2. It's a pain in the ass, but it is
> what is. "Make a change and call it progress" All I want a boot loader
> to do is load the OS I want and the latest kernels and then leave me
> alone. But the developers are doing this for free so who am I to complain!

--
## Przemysław Kulczycki >><< Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

I have also experienced this bug on both the HP G60-231WM & the Acer Aspire 3690-2900 -- the fix is very simple... so simple you will think "Why didn't I think of that???"

Ok so mouse doesn't work after upgrade to 9.10... then press CNTRL/ALT/F1 to get yourself to the Command Line...

First login to root account, then goto /boot/grub/ folder to edit the menu.lst file. This must be done because something went wrong with the UPGRADE and your GRUB menu.lst DID NOT Update itself. So you can edit it menu.lst with "nano menu.lst" --- once in nano then look for your Ubuntu install id and change the First entry from 2.6.28-11(last set of numbers in your menu will be the latest version of the install prior to the upgrade. you will need to change it to this 2.6.31-14-generic --- leave everything else alone just change the Kernel Version and save then restart and Touchpad will be working again just fine

to get back to desktop once mods are doen use CNTRL/ALT/F7

This moved me from being stuck at 2.6.31-14-generic to 2.6.31-16-generic, it allso filled in the menu for 15

sudo chmod 777 /boot/grub/grub.cfg
sudo grub-mkconfig > /boot/grub/grub.cfg
sudo chmod 444 /boot/grub/grub.cfg

I just took the latest kernel 2.6.31-17-generic and again had to apply the hack I listed above.
update-grub continues to update the menu.lst rather than grub.cfg

mike,

the issue you describe is unrelated to this bug report, and results from your having installed the legacy 'grub' package, replacing the grub-pc (grub2) package included Ubuntu 9.10. To resolve this, you should run 'sudo apt-get install grub-pc' to pull grub2 back in.

Hi people,

I've put together a little script that should be placed under:

/etc/grub.d

Since I'm pretty sure that there are plenty of corner cases, I encourage you to try it and:

1) Report success/failure.
2) Send patches based on it !

You can run this by simply instantianting it:

sh /etc/grub.d/50_cleanup

It's quite ubuntu/debian specific, but hey, works for me ;)

I've been trying with other workstations/setups and I've added some corrections on their particular case, as well as a warning regarding "updatedefaultentry" and "savedefault" menu.lst options.

Please keep in mind that, according to menu.lst, changing the "savedefault" setting could break dmraid-based setups.

Bear in mind that this script has been tested on 9.10's with grub (not grub2), when trying it on a 9.04:

.: 39: Can't open /usr/lib/grub/grub-mkconfig_lib

Another fix/workaround should be found then :-S

After install new -image- package, update-grub2 doesn't run. Lucid.

To retain compatibility with 9.04 I've just moved the only external function (grub_file_is_not_garbage) that was used in the script. Now it should work with Jaunty and maybe other previous releases.

Artur, can you further detail the commands you issued and the output ? Please also keep in mind that, as I warned, this has only been tested on grub1, not on grub2.

This isn't a patch that fixes the bug but a script that works around the issue to get things working again. Unsubscribing reviewers.

On upgrade to Lucid, grub2 was NOT installed for me; not sure if it should have been.

Therefore, I am still experiencing this bug in Lucid. I resolved it by backing up my menu.lst (renaming it to menu.lst.backup), and then running update-grub. New menu.lst had correct entries. (If you copy menu.lst instead of renaming it, make sure you delete the original and keep the copyl for this to work!)

Also, on upgrading to kernel 2.6.32-22-generic through update-manager, I was NOT given the option of keeping the original or installing the package maintainer's version. Therefore, it is possible that this issue was not caused by update-grub on my system; however, my experiences were identical to those above when updating menu.lst through update-grub.

Hope that all makes sense and is of some use.

WIth the Lucid release, there are installed both:
~$ ls /usr/sbin/update-grub*
/usr/sbin/update-grub /usr/sbin/update-grub2

Added lines in /etc/grub.d/40_custom are NOT incorporated into /boot/grub/grub.cfg with usage of
$ sudo update-grub

However there is success if there is used
$ sudo update-grub2
the desired lines are added.

$ update-grub --version
grub-mkconfig (GRUB) 1.98+20100804-5ubuntu3
$ update-grub2 --version
grub-mkconfig (GRUB) 1.98+20100804-5ubuntu3

Both not work: properly listed items on terminal during updating, not shown in boot menu after restart.
But when auto-update installs new kernel image, result is correct (new kernel appear in boot menu).

> ... menu.lst
I not found any menu.lst on my machine:
$ find / -name "*menu.lst*"
/usr/share/doc/memtest86+/examples/grub-menu.lst
$

Ubuntu 10.10

To comment #67: after boot another (old) Ubuntu from 2nd partition and running update-grub2 under it, boot menu was fixed, but only until i modify it again.

Hi just encountered a similar issue after upgrading to Natty.
The menu.lst was refusing to update (I believe I've still got grub installed not grub2) with the 11.04 kernels.
I've just backed up my menu.lst and recreated it using update-grub and new kernels appear to have been added correctly.
I've now added back in the original dual boot lines and am going to reboot.

Only noticed it after upgrade and running uname -r to install headers and noticed that the kernel was different to headers available in synaptic.

uname -a (running 11.04 using menu.lst before correction)
Linux brownie-safe-config 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:48 UTC 2011 i686 i686 i386 GNU/Linux

Jim

this still is a problem with lucid, some 18 months after its relese. would it be a good idea to fix this?

as for the public, this is not a minor bug, having servers running old kernels is a security issue

This should not be flagged medium - it's a serious bug in that the kernel isn't upgraded without manual override. Please upgrade this to major

I am having this problem with grub legacy in Natty. I just realized that despite update-manager downloading new versions of the kernel and running update-grub with apparent success, that my menu options only go as high as 3.0.0-12 when the latest installed version is 3.0.0-15.

Sorry, meant to say Oneiric, not Natty.

I'm having same problem in Oneiric too and the strange fact is that the Upgrade from Natty to Oneiric didn't upgrade my grub installation keeping Grub legacy instead of Grub2. About last issue, i don't know if this behaviour is correct or not.

I got my system unbootable after deleting some "old" kernels, then spent about an hour recovering the system, debugging and trying to figure out why update-grub is not doing what is saying it's doing.

I'm using latest Ubuntu, of course.

There should at least be an HUGE warning when one runs update-grub saying "I am doing nothing because of an unsolved ingenuous bug from 2008".

None of the affected versions reported here are supported versions; and grub legacy upstream is also stopped, only receiving possible random fixes locally