[MASTER] Grub does not update menu.lst when it was hand-edited (so it defaults to old 2.6.28 kernel after upgrade to ubuntu 9.10 from 9.04): add 'help' details to debconf prompt

[LimCore]

Release notes for this issue can be found at
<https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes#GRUB%20menu.lst:%20install%20the%20maintainer%27s%20version%20vs.%20keep%20the%20local%20version>. If running 'sudo update-grub' does not add a boot entry to /boot/grub/menu.lst for the Ubuntu 9.10 kernel (2.6.31), please follow the instructions there.

I just upgraded 9.04 to 9.10

System still boots the old kernel 2.6.28-13-generic instead of current one 2.6.31..

If I run reinstall of linux-image for 2.6.13 then grub says it updated menu.lst, but it did not.

Lets look:

uname -a
Linux lcwood 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

[...]
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.31-14-generic
Found kernel: /vmlinuz-2.6.28-13-generic
Found kernel: /memtest86+.bin
Updating /boot/grub/menu.lst ... done
[...]

And then:

root@lcwood:~# cat /boot/grub/menu.lst | grep 31
root@lcwood:~#
so nothing.

Attaching full output of installer on reinstall, and full menu.lst after that.

[LukasThyWalls (thywalls)]

This affects me to.

I can boot with the last kernel used in Jaunty, but I had two kernels installed in Jaunty, and when i upgraded to Karmic, one new Kernel was installed but the menu.lst wasn't updated. update-grub said the same than LimCore.

I rename menu.lst, and generated other one, and all update-grub works again creating a fresh menu.lst without problems. But if i had deleted all my old kernels, i hadn't could boot anymore.

[LimCore (limcore)]

Same work around works for me it seems, well I removed (or - moved) the old /boot/grub/menu.lst
and then run grub - by reinstalling linux-image-... package,
and then it worked.

[LimCore (limcore)]

Btw, http://linux.slashdot.org/story/09/11/03/2211231/Some-Early-Adopters-Stung-By-Ubuntus-Karmic-Koala

[LimCore (limcore)]

LukasThyWalls,

our problems seems like duplicate of bug #470265

But, there, the workaround is to execute grub-update by hand it seems, and you said this work around did not work for you?

[LukasThyWalls (thywalls)]

LimCore, i think is not related to that bug, this bug fits better.

"sudo update-grub" didn't update the menu.lst until i deleted (and did a backup of) the original menu.lst, and then, calling "sudo update-grub", i generated a good menu.lst with the new kernels installed. In that bug, says "sudo update-grub" works always, and for me, didn't work until i deleted the old menu.lst.

When ubuntu launch a new kernel, i will see if i had problems again, now, i can't test.

[Steve Langasek (vorlon)]

Bug #470265 is an exceptional case where the user's /etc/kernel-img.conf is missing the hooks that are supposed to be set up as part of every install. So far, that bug has been unreproducible for anyone else.

The usual cause for the problem you're seeing is that you have manually edited your menu.lst, then on upgrade you've answered when prompted that you want to keep these local changes instead of letting update-grub overwrite them. Is this the case for you?

If so, please review the changes you've made to your menu.lst and apply them to the "Default options" section of variables in menu.lst, as documented in the same file; then run 'sudo update-grub' and choose "install the package maintainer's version" instead of the default "keep the local version currently installed".

We're vigilant for any failures to configure the correct kernel on upgrade resulting from other than an explicit user decision, but aside from the one odd and unreproducible case you've pointed to, so far we're not aware of any. I sympathize with users who find themselves in this situation unexpectedly, but that prompt on upgrade - and the default value f "keep the local version" - are there precisely because in previous versions of Ubuntu, local changes to menu.lst would be lost without warning. There's little we can do to improve this further without scrapping the menu.lst format entirely... which is exactly what we're doing by switching to grub2 by default for new installs in Ubuntu 9.10.

Since this problem seems to be affecting a surprising number of users for Ubuntu 9.10, I'll be adding a note about this to the Ubuntu release notes. We will also look at whether the text of the prompt can be clarified without causing a regression for non-English-speaking users.

[LukasThyWalls (thywalls)]

I attached the backup of the file that i can't update with "sudo update-grub", althought update-grub said the update was ok.

I didn't modify manually the menu.lst, i reinstalled Jaunty five days before I upgrade to Karmic. The only modification was with kgrubeditor, but in the past, i had modified my boot with this program, and the kernels upgrade worked well always.

[Steve Langasek (vorlon)]

"kgrubeditor" qualifies as manual editing. This tool does not interact reasonably with Ubuntu's update-grub, and was removed from the Ubuntu 9.10 release for this reason.

[LukasThyWalls (thywalls)]

I know that "kgrubeditor" had been removed in Karmic for that, but it update always the Kernels in Jaunty without problems, and in the upgrade to Karmic, i didn't say to keep grub options.

If this is the problem, ok, but others persons with this problem are using older kernels (with its problems) and maybe they don't know that, or don't know how to fix it. Somebody could create a update-package to inspect and fix this problem if is present, i don't know, but "kgrubeditor" was the recommended ubuntu package to manage grub loader, and it could be the problem for many users.

In other way, What are the better package for manage grub loader now in Karmic?

[LimCore (limcore)]

Hi, I was editing the previous menu.lst - to disable splash.

Attaching the old menu.lst (that was used when the upgrade from 9.04 to 9.10 was done)

[Steve Beattie (sbeattie)]

On Wed, Nov 04, 2009 at 10:13:10PM -0000, LimCore wrote:
> Hi, I was editing the previous menu.lst - to disable splash.
>
> Attaching the old menu.lst (that was used when the upgrade from 9.04 to
> 9.10 was done)

It looks like you were editing the menu items directly to do this; the
preferred way is to edit the line:

  # defoptions=quiet splash

to something like

  # defoptions=

if you want neither quiet mode and no splash and then run update-grub,
so that it regenerates the menu entries.

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

[LimCore (limcore)]

Ok this is clear now;

But I think there should be some warning messages
1) when running grub-update - that newest kernel is for some reason not used
2) perhaps also when running ubuntu - some information that older kernel then the recommended kernel is being used?

because, otherwise users will have no idea what is wrong and why for example some hardware is not working or something

[Steve Langasek (vorlon)]

Preliminary documentation added to <https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes#GRUB%20menu.lst:%20install%20the%20maintainer%27s%20version%20vs.%20keep%20the%20local%20version>:

If you have previously modified the {{{menu.lst}}} bootloader configuration for GRUB, either by hand or with a tool such as {{{kgrubeditor}}}, you may be asked on upgrade whether you wish to keep your local version of the menu.lst or install the package maintainer's version. This question is asked because such changes cannot be merged automatically with 100% reliability, and care is taken to not overwrite the user's manually edited bootloader configuration without warning.

However, if you choose to "keep the local version currently installed," your system will not be set up to boot from any newly-installed kernels. '''Manual action is required on your part to ensure that your system is running the current, security-supported kernel after upgrade.''' If you have local changes to your bootloader config that you want to keep, it is recommended that you follow these steps:

 * Choose "keep the local version currently installed" at the prompt.
 * Open {{{/boot/grub/menu.lst}}} with a text editor (e.g., {{{sudo gedit /boot/grub/menu.lst}}}).
 * Apply any changes you've made to the kernel boot options to the commented variables (e.g., {{{groot}}}, {{{kopt}}}, {{{defoptions}}}) above.

 * Move any manually-added boot options for other operating systems so that they are above the line {{{
### BEGIN AUTOMAGIC KERNELS LIST
}}} or below the line {{{
### END DEBIAN AUTOMAGIC KERNELS LIST
}}}
 * Save the file, and run {{{sudo update-grub}}} from the commandline.
 * Choose "install the package maintainer's version".

For example, if you added an option `i915.modeset=0` to the "kernel" line:

{{{
kernel /vmlinuz-2.6.31-14-generic root=UUID=0e7... ro quiet splash i915.modeset=0
}}}

then add this option to {{{kopt}}}:

{{{
# kopt=root=UUID=0e7... ro i915.modeset=0
}}}

An updated version of the {{{grub}}} package will include information about this problem in the help screen for the {{{menu.lst}}} prompt. (Bug:470490)

N.B. This last line is not yet settled; still discussing whether it's worth an SRU, since the only place we can put a warning is in the extended 'help'.

[LimCore (limcore)]

Thanks;

We can perhaps improve it more in following way:

If grub sees kernels A,B,C (found kernel), but it parses final menu.lst and sees that only A and B are used (while C is newest),
then it will just ask whether to generate default entry for C and prepend it (leaving rest of the config as hand-edited as it was).

Found kernel: /vmlinuz-2.6.31-14-generic
Found kernel: /vmlinuz-2.6.28-13-generic (NOT USED)
Warning: new kernel 2.6.31-14 is not selected to be used (probably because menu.lst was hand-edited before).
Should I generate entry to allow usage of 2.6.31-14? (Y/n): ...

^- something like that?

[Steve Langasek (vorlon)]

LimCore,

There are a number of practical problems with the approach you suggest that make it unsuitable for an SRU change to Ubuntu 9.10.

For Lucid, we will hopefully have gotten rid of this problem by migrating to grub2 on upgrade.

[Steve Langasek (vorlon)]

LukasThyWalls,

I wouldn't say that kgrubeditor was updating "without problems"; all of the kernel boot stanzas in your earlier menu.lst are missing the "uuid" line to tell grub which disk to look at for the kernel and initramfs files.

If you didn't tell grub on upgrade to keep the existing file, then that suggests there's another bug here, preventing display of the prompt in some cases. Have you done something to your configuration to force all upgrades to be non-interactive?

> i don't know, but "kgrubeditor" was the recommended ubuntu package to manage
> grub loader, and it could be the problem for many users.

Recommended by whom? kgrubeditor had known problems working together with update-grub prior to Ubuntu 9.10; if there's documentation somewhere recommending its use, we should probably get that corrected.

> In other way, What are the better package for manage grub loader now in Karmic?

None, except for a text editor. Why does your bootloader require ongoing management?

[LimCore (limcore)]

Steve, btw, there are many bugs, like cryptsetup-no-prompt-needs-nosplash or sound-driver-needs-kernel-option afair, and cstate cpu c3 bug - that are fixed (or worked around) by certain kernel options.

[Steve Beattie (sbeattie)]

On Thu, Nov 05, 2009 at 08:16:59PM -0000, LimCore wrote:
> Steve, btw, there are many bugs, like cryptsetup-no-prompt-needs-
> nosplash or sound-driver-needs-kernel-option afair, and cstate cpu c3
> bug - that are fixed (or worked around) by certain kernel options.

That is certainly true, but rather than modifying the menu items
directly, the recommended mechanism to do so with grub 1 in ubuntu is
to edit '# kopt=' line or the '# defoptions=' line in the AUTOMAGIC
KERNELS comment section and re-run update-grub so that it regenerates
the menu entries. Doing so also means that on kernel updates, the
same options will be applied to the menu entries for the new kernels.

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

[Mark (mnd999)]

I make this much worse than the previous kernel, the wireless now doesn't work at all. It connects but as soon as you try to use it it stops working.

Linux markspc 2.6.32-12-generic #16-Ubuntu SMP Thu Jan 28 07:47:05 UTC 2010 x86_64 GNU/Linux

Feb 5 19:20:58 markspc kernel: [ 64.401374] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 5 19:20:58 markspc kernel: [ 64.401452] cfg80211: Calling CRDA for country: GB
Feb 5 19:20:58 markspc kernel: [ 64.403336] cfg80211: Regulatory domain: GB
Feb 5 19:20:58 markspc kernel: [ 64.403338] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 5 19:20:58 markspc kernel: [ 64.403341] (2402000 KHz - 2494000 KHz @ 40000 KHz), (10000 mBi, 10000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403345] cfg80211: Regulatory domain: GB
Feb 5 19:20:58 markspc kernel: [ 64.403346] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 5 19:20:58 markspc kernel: [ 64.403349] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403352] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403354] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403357] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403361] cfg80211: Regulatory domain: 98
Feb 5 19:20:58 markspc kernel: [ 64.403362] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 5 19:20:58 markspc kernel: [ 64.403365] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.403374] cfg80211: Current regulatory domain updated by AP to: GB
Feb 5 19:20:58 markspc kernel: [ 64.403376] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 5 19:20:58 markspc kernel: [ 64.403378] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Feb 5 19:20:58 markspc kernel: [ 64.439043] Intel AES-NI instructions are not detected.
[ 3079.295894] wlan0: deauthenticating from 00:1f:f3:f9:a1:cd by local choice (reason=3)

[Jano (jkotuc)]

I once selected the option "keep the local version currently installed", and now I'd like to CHANGE it, to "install the package maintainer's version". In other words, I'd like to see that question window AGAIN and select a different option than last time. How do I do it? I can't find any helpful info on the Web... Please help if you can. THX

[Milan Bouchet-Valat (nalimilan)]

Jano: See comment #5 above.

[Jano (jkotuc)]

Milan: Thanks for your response, but that doesn't solve my problem. First, I have newer Grub version, with no menu.lst (grub.cfg takes its place). Second, my Grub config files DO get updated after a new kernel upgrade, but in a way I don't like. That is, new entries are added to Grub boot menu ALONGSIDE the existing ones, instead of REPLACING the older entries.

For example, after the recent kernel upgrade from version 2.6.31-20 to 2.6.31-21, I ended up with both of these kernels being available in the Grub menu. Then I had to uninstall the older version (image and headers) manually to save disk space (~150 MB).

The behavior I'd like to have, is an older kernel automatically being replaced by the upgrade, so that I don't have to perform any additional steps. It all boils down to having selected a wrong option ("keep the local version currently installed") when I was upgrading kernel for the FIRST time. It was a stupid mistake which I don't know how to correct and can't find any information about...

[Steve Langasek (vorlon)]

On Mon, May 03, 2010 at 09:16:19AM -0000, Jano wrote:
> Milan: Thanks for your response, but that doesn't solve my problem.
> First, I have newer Grub version, with no menu.lst (grub.cfg takes its
> place).

Then whatever issue you're experiencing is unrelated to this bug.

> The behavior I'd like to have, is an older kernel automatically being
> replaced by the upgrade,

Yes, that's definitely unrelated...

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

[Robert Osowiecki (robert-osowiecki)]

This bug hit me by suprise -- i thought that nvidia drivers were broken https://bugs.launchpad.net/ubuntu/+source/grub/+bug/590136

[gigastress (a9711599)]

Hey guys,

I just proceeded from 9.10 to 10.4 LTS lucid, after not upgrading for 2.5 years, I was about to proceed to the latest version.
I decided to keep the old grub, for I made a whole-disk-encryprtion and wanted to keep the settings. I dont know if this is the problem with lvm problem adressed in the lucid release notes. I think I installed the new kernel but Im not sure here.
Anyway the result of this installation is, that
When I boot, the display where Im supposed to put in the LVM/luks password is showing up, but when I put it in, it keeps saying - cryptsetup failed, bad password or options -
It is the correct pass, the release note said sth. about changing the UUID in the fstab with the actual name of the hd, but since the display where Im supposed to put in the LVM/luks password is showing up at boot, I dont know if this problem is related.
so it actually could be a kernel, fstab, or grub problem.
I got know idea how to handle this.
suggestions would be highly appreciated.
anyone, how can I proceed ???

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".