Kernel update hoses hand-edited menu.lst

[Manni]

I just updated my system to the new kernel. Now grub no longer lists Windows in its boot menu. I checked /boot/grub/menu.lst and, indeed, the entry that booted Windows is gone.

Comment from developer: You shouldn't put stuff between these lines:

### BEGIN AUTOMAGIC KERNELS LIST
### END DEBIAN AUTOMAGIC KERNELS LIST

because that will be regenerated every time update-grub is run.

[Andrew Fenn (andrewfenn)]

Hi,

Can you include a few more details such as the following:

- Which version of Ubuntu you are using
- What version of the new kernel you updated to
- A copy of your menu.lst

[Manni (ubuntu-lxxi)]

I am Using Unbuntu Edgy.

I obviously am not able to provide a copy of the original menu.list file (since the update changed that one thouroughly).

I'll look up the kernel version when I get home.

[Manni (ubuntu-lxxi)]

Here's my current kernel version (as reported by uname -a):

2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux

[Windkracht8 (windkracht8)]

This problem has occurred on my pc a couple of times during kernel update as well.
And I found out that if you put the other OS's in front of the automatic list. It will get removed from the list when it's updated by apt-get/synaptic.
If you put the other OS's at the end, they will remain there during update.

Running kernel "2.6.17-11-generic" on Ubuntu 6.10.

[MartinE (martin-engbers-gmx)]

I'm using Edgy and Feisty on one machine, and I can confirm that this bug exists in Feisty. In Feisty's menu.lst file (the one that grub uses when booting), the first entries are for Edgy Eft, followed by the entries for Feisty Fawn. Whenever I update Feisty's kernel, the Edgy lines are gone from the menu.lst and I have to manually add them again. I noticed this behavior in all kernel versions from 2.6.20-6 to the most recent 2.6.20-8, in both the 386 and the generic versions (i'm using an athlon, so this would be the 686 kernels).

I didn't notice the bug in Edgy Eft, but this is entirely consistent with Windkracht8's observation concerning the order of entries in the menu.lst file.

[Timo Aaltonen (tjaalton)]

Windkracht8: that's normal behaviour, you shouldn't put stuff between these lines:

### BEGIN AUTOMAGIC KERNELS LIST
### END DEBIAN AUTOMAGIC KERNELS LIST

because that will be regenerated every time update-grub is run. Notabug.

MartinE: likewise. Added to that, it is impossible to support multiple Linux-installations on one computer where /boot can be a separate partition or not, and race conditions occur etc. You have to do it manually.

[Manni (ubuntu-lxxi)]

OK, thanks Timo. I guess this explains things.

But let me suggest to modify the comments in menu.lst so that a human being not familiar with the update process might actually understand them:

### 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

That's pretty clear (at least now), but I guess one could add something like "manual changes will be lost during the next upgrade". "Modified" doesn't sound dramatic enough, if you know what I mean.

[Casey Stamper (casey-stamper)]

I had the same issue and didn't even have the commented text in menu.lst. I have a dual-boot (XP & Feisty) and upon updating the kernel last night, the option for XP disappeared from the boot selection list and from menu.lst. It's easy enough to fix but I can envision a more non-technical user having a panic attack upon observing this behaviour. Is there a limit to the number of entries in menu.lst? Maybe XP's entry was pushed out because of that?

[GKinal (gkinal)]

Could someone give a CLEAR explanation of how the automagic kernels list markers work ? Are the BEGIN and END lines sup posed to have zero, one, two, or three hashes (#) for them to have any effect ? If they are composed properly, and if the non-Linux boot stanzas are put in the "correct" place (AFTER, if I read correctly), will they be retained after a kernel upgrade ?

I am setting up a triple-boot computer for a relative. We like Ubuntu. However after last night's kernel upgrade, recommended by the automatic upgrade manager, the grub menu no longer showed the other OS choices.

I knew enough about how to re-edit the menu.lst, using the backup file (menu.lst~), but the typical user would not.

I also know I can prevent (block) such future automatic kernel upgrades, but that is a totally unacceptable solution, locking the owner in to an eventually obsolescent kernel.

HELP please.

G. Kinal

[ZaNi (zani5971)]

I cannot explain hot the kernel list markers work, but I have found a simple (albeit hackish) solution to the problem. I create a copy of the good menu.lst before any modifications can be made to it ("sudo cp /boot/grub/menu.lst /boot/grub/menu.lst.bkp"), then whenever the list gets scrubbed, it's a simple "sudo cp /boot/grub/menu.lst.bkp /boot/grub/menu.lst" to restore the original list.

The second part can be placed in a script on the desktop or home folder for those who don't like using the terminal (though it would need to be modified to remove the 'sudo' requirement ideally). You could either get the user's to run this file whenever the list is scrubbed, or (ugh) set it to run on startup... Obviously this is not ideal, but it is the best I can offer.

Hopefully that will help as a temporary solution until a more permanent fix is implemented.

[Tormod Volden (tormodvolden)]

> Is there a limit to the number of entries in menu.lst?

You can limit the number of kernel entries with the "# howmany=" option.

[thoralf (thoralf-schulze)]

just came across this issue as well (feisty fawn). the bad thing is that the update process doesn't even back up menu.lst:

root@susi-schleppi:/boot/grub# ls -al me*
-rw-r--r-- 1 root root 4717 2007-12-19 14:56 menu.lst
-rw-r--r-- 1 root root 4717 2007-12-19 14:56 menu.lst~
root@susi-schleppi:/boot/grub#

both files are indentical.

i'd also like to second mannis suggestion to change the comments in menu.lst to reflect this behaviour ... it might also be a good idea to split up the boot options into two sections (one that will be overwritten by update-grub and another one that won't be touched by this script).

with kind regards,
thoralf.

[Eduardo Fonseca (edufons)]

I had the same problem in the last kernel update in two machines, one with Feisty and other with Gutsy. I have edited menu.lst leaving XP as first entry and as default because of my parents but it was wiped out.

The point is, when Ubuntu (in my case, Kubuntu) is installed, it detects XP partitions an put the entry between Debian Automagic Kernel List stanzas. In previous kernel updates, GRUB update detected XP as if it was a new Ubuntu installation, changing the default system to Ubuntu but not erasing XP entry.

This time it erased XP entry that actually was among automagic detected, but I kept there because this is the way Ubuntu does in a clean install. I also thing this problem would scare new/light users that would think XP was erased or wouldn't know how to access it.

supdate-grub must always detect other systems. It would be better if it could keep previous changes.

[Eduardo Fonseca (edufons)]

Well,... correcting myself, Ubuntu put the other systems after Automagic List. I have changed the position myself and it was my mistake. But still, this didn't happen in previous kernel updates, erasing the XP entry from automagic entries. Why this time it was different?

[Steve Langasek (vorlon)]

This bug has been fixed in hardy, in grub version 0.97-29ubuntu7 and above:

grub (0.97-29ubuntu7) hardy; urgency=low

  * debian/update-grub: use ucf to record changes to the autogenerated
    kernel list

It is still advisable that boot options for other operating systems such as Windows be added outside the "automagic kernels list" markers, but going forward users will receive a debconf warning from update-grub if the update will overwrite local changes.