Default update-grub behaviour is not intuitive with respect to user modifications

You must place custom entries according to the instructions in the comments in
menu.lst

(In reply to comment #1)
> You must place custom entries according to the instructions in the comments in
> menu.lst

Well, I've made no custom entries to my menu.lst. Ubuntu installer puts the
entries into the file:
Ubuntu Kernel, Ubuntu Kernel (recovery), memtest and Windows. I never ever
toutched the file before I installed a new kernel.

Works fine here. The installer places the entries in the correct place. Please
attach your menu.lst.

Perhaps you modified the file after installation?

It sounds like you may be experiencing bug #21175

Created an attachment (id=3813)
menu.lst

My menu.lst *after* I have modified it to match all my installed OSes again.

(In reply to comment #4)
> It sounds like you may be experiencing bug #21175

I'm not shure. I can boot windows, when I edit my menu.lst from hand (or at grub
prompt) very well. I also can mannualy mount my windows ntfs partition. I don't
think that this is a duplicate of #14947

*** Bug 23248 has been marked as a duplicate of this bug. ***

To clarify this bug, since it's evolved a bit:

The following things are confusing about the current behaviour:

- 'kopt' and such are treated as configuration parameters, but written in the
form of comments. Users naturally uncomment them.
- The automagic update markers are surprising. Users add new entries to the
list, which seems reasonable, but then they disappear the next time update-grub
is run.
- Similarly, parameters which are added to the automatic stanzas are
unexpectedly lost

This is compounded by the fact that this is essentially an extended version of
upstream's config file syntax. People who know menu.lst from elsewhere should
not expect to have things behave so differently.

The comments which explain this are buried in the middle of the file and often
overlooked, but I don't think that even a prominent comment excuses this kind of
surprising behaviour.

*** Bug 23496 has been marked as a duplicate of this bug. ***

As my bug report was a duplicate of this one, I would like to add something from
my original report. The file /boot/grub/menu.lst~ should be a backup of the file
/boot/grub/menu.lst before any modifications are done to it. ATM it seems that
both these files are always exactly the same after an update.

*** Bug 24389 has been marked as a duplicate of this bug. ***

To get Windows (or any other OS) to appear first in the list, it is necessary to add it BEFORE the Automagic section, which is before all the Options and example comments, which is less than ideal. It would be OK to have an "Ubuntu" section with all its kernels, as long as you can add entries before and after as needed/desired, without having to go above the options and comments section.
It is able to leave my Splashimage line alone in Dapper, which it didn't previously, so it should be able to do the same for non-Ubuntu entries.

All this would be moot if there were a proper Graphical Grub editor, which is a separate issue.

Adding the Windows boot options before the Automagic lines results in the Splashimage not appearing, so the bootlist really has to come after all the options, so there is no proper way of reordering the bootlist with anything before Ubuntu.

If changing this, note that there are installer implications and that this needs to be handled carefully. In general this needs careful design to ensure that the result isn't just as bad ...

Colin, is something we have a realistic hope of addressing for Gutsy or should we spec up better grub management as a feature for Gutsy+1? (we could also do with a boot config GUI)

On Wed, Sep 05, 2007 at 07:58:22AM -0000, Henrik Nilsen Omma wrote:
> ** Changed in: grub (Ubuntu)
> Target: None => ubuntu-7.10-beta

Unfortunately, fixing this isn't straightforward, and requires designing a
different solution, documenting it, and hopefully pushing it up to Debian to
avoid diverging forever. As Colin notes, it also affects the installer.

As such, I don't think it's practical to target it for 7.10. I think this
would be a natural target for 8.04 LTS though.

--
 - mdz

I agree with mdz, of course. Untargeting from Gutsy.

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.

On Mon, Jan 28, 2008 at 09:56:25PM -0000, Steve Langasek wrote:
> 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.

This is certainly an improvement, but it seems to always trigger on the
first upgrade to 0.97-29ubuntu7 or later, even if the file hasn't been
modified. Is it possible to fix that, so that it's silent unless the user
actually modifies the file?

--
 - mdz

Matt,

In my pre-upload tests, I did not find that the first upgrade to 0.97-29ubuntu7 triggered a ucf prompt except in the case where there was already a detectable difference between the magic comments and the kernel list. This is AFAICS a necessary evil in order to get the current state of the config file registered with ucf; waiting until the first kernel upgrade only increases the chances of a ucf prompt that might have oterwise been avoided, but it should not result in any prompts where the menu.lst has not been locally modified. Can you provide a copy of a menu.lst that results in a prompt when you think it shouldn't?

On Tue, Jan 29, 2008 at 12:07:01AM -0000, Steve Langasek wrote:
> In my pre-upload tests, I did not find that the first upgrade to
> 0.97-29ubuntu7 triggered a ucf prompt except in the case where there was
> already a detectable difference between the magic comments and the
> kernel list. This is AFAICS a necessary evil in order to get the
> current state of the config file registered with ucf; waiting until the
> first kernel upgrade only increases the chances of a ucf prompt that
> might have oterwise been avoided, but it should not result in any
> prompts where the menu.lst has not been locally modified. Can you
> provide a copy of a menu.lst that results in a prompt when you think it
> shouldn't?

Attached are /boot/grub/menu.lst and /boot/grub/menu.lst~. Assuming this is
the backup from ucf, this should be what you need. Notice that all of the
"kernel" lines are unmodified.

I saw exactly the same behaviour on both my desktop and my laptop upon
upgrading to this version of grub. The laptop was a fresh 7.10 install
upgraded to Hardy, with very little customization.

--
 - mdz

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

### 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=daf1bf61-d974-4e90-b2c7-5f4dfa4e56cf ro

## Setup crashdump menu entries
## e.g. crashdump=1
# crashdump=0

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)
...

I have such a partition configuration:
/dev/sda1: /boot
/dev/sda2: swap
/dev/sda3: windows
/dev/sda5: /
/dev/sda6: /home

In my menu.lst file I have lines containing: "root (hd0,0)" which is true. Nonetheless, after every kernel update, it automatically changes to "hd(0,1)" which breaks running of Ubuntu, forcing me to manually change it back.

It's not very much problem for me, but I also installed Ubuntu at my family's computer and it's strange if GRUB gets broken after just an update.

My (PROPER!) /boot/grub/menu.lst ends with that:
"## ## End Default Options ##

title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,0)
kernel /vmlinuz-2.6.22-14-generic root=UUID=27771eab-0c14-46c4-86cc-3883a332c1c5 ro quiet splash
initrd /initrd.img-2.6.22-14-generic
quiet

title Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root (hd0,0)
kernel /vmlinuz-2.6.22-14-generic root=UUID=27771eab-0c14-46c4-86cc-3883a332c1c5 ro single
initrd /initrd.img-2.6.22-14-generic

title Ubuntu 7.10, memtest86+
root (hd0,0)
kernel /memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST
(...)
"

On Tue, Jan 29, 2008 at 09:36:12AM +0000, Matt Zimmerman wrote:

> Attached are /boot/grub/menu.lst and /boot/grub/menu.lst~. Assuming this is
> the backup from ucf, this should be what you need. Notice that all of the
> "kernel" lines are unmodified.

> I saw exactly the same behaviour on both my desktop and my laptop upon
> upgrading to this version of grub. The laptop was a fresh 7.10 install
> upgraded to Hardy, with very little customization.

FWIW, this was tracked down to a difference in the content of the entries
being written out by grub based on the output of 'lsb_release -d', and was
resolved in grub 0.97-29ubuntu14.

There have been some further issues with upgrades from 6.06 to hardy on
account of differences in the overall behavior of update-grub in those older
versions; these issues are tracked as bug #187362.

On Wed, Feb 27, 2008 at 06:04:02PM -0800, Steve Langasek wrote:
> FWIW, this was tracked down to a difference in the content of the entries
> being written out by grub based on the output of 'lsb_release -d', and was
> resolved in grub 0.97-29ubuntu14.

Thanks for following up.

--
 - mdz

Hi Steve,

Thanks very much. I don't understand all the details but to hear it's been fixed makes me happy :)

BR,
Cheski

----- Original Message ----
From: Steve Langasek <email address hidden>
To: <email address hidden>
Sent: Thursday, February 28, 2008 3:04:02 AM
Subject: Re: [Bug 21412] Re: Default update-grub behaviour is not intuitive with respect to user modifications

On Tue, Jan 29, 2008 at 09:36:12AM +0000, Matt Zimmerman wrote:

> Attached are /boot/grub/menu.lst and /boot/grub/menu.lst~. Assuming this is
> the backup from ucf, this should be what you need. Notice that all of the
> "kernel" lines are unmodified.

> I saw exactly the same behaviour on both my desktop and my laptop upon
> upgrading to this version of grub. The laptop was a fresh 7.10 install
> upgraded to Hardy, with very little customization.

FWIW, this was tracked down to a difference in the content of the entries
being written out by grub based on the output of 'lsb_release -d', and was
resolved in grub 0.97-29ubuntu14.

There have been some further issues with upgrades from 6.06 to hardy on
account of differences in the overall behavior of update-grub in those older
versions; these issues are tracked as bug #187362.

--
Default update-grub behaviour is not intuitive with respect to user modifications
https://bugs.launchpad.net/bugs/21412
You received this bug notification because you are a direct subscriber
of a duplicate bug.

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

The ucf changes in 0.97-29ubuntu7 seem to have broken some update-grub workflows.

In gutsy and before, you could setup a basic menu.list containing update-grub options but no kernels, run update-grub, and get your kernels correctly added to the menu.lst file. Now, if a menu.lst exists at all when you run update-grub, it won't insert new kernels. Also, if you remove kernels from menu.lst, there's no way to get them back automatically, other than removing menu.lst entirely and running update-grub. Is there some magical string I need to put in my menu.lst to get it to add kernels that aren't already there?

Ted Cabeen: The exact same thing is happening to me. I filed this as a separate bug report: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/229656

I've just updated again the kernel and the update-grub bug is still happens.
Today (07/06/08) I've updated the system through update manager and the kernel was updated to 2.6.24.18.20.
Then ucf ask for an option about what to do with menu.lst option, and i selected 1st ("used the new proposed" or something similar).
So update-grub updates the kernel list, but changes disk id:

 root=hd(0,5) -> root=hd(0,0)

I've to say that is a partition with winxp, but it hasn't to be a cause for such a bug.
In a new user, it means a broken system and could be hard to fix. For experienced user, a simple livecd boot will help to access to the filesystem and fix it.

I've installed ubuntu 8.04 in a fresh install and every kernel update i've the same bug. (2 kernel updates from ubuntu release at 21/04/08).

More info:
linux-image-generic 2.6.24.18.20
grub 0.97-29ubuntu21

parq,

The fix for this bug is that, when your locally-modified menu.lst disagrees with how update-grub would calculate the boot entries, a warning is shown letting you know about this inconsistency. There is no way that we can reliably "fix" the fact that the autogenerated entries don't match your local modifications, because the generated entries are generated based on the kopt and groot values that you didn't modify. The best we can hope to achieve, short of migrating to a completely different config syntax (grub2), is to warn the user about inconsistencies, which is indeed what has been done here.

To ultimately resolve this inconsistency on your system, you should update the groot variable within menu.lst and re-run update-grub.