After a kernel update, I am asked what to do with the old menu.lst. The wrong choice is offered by default.

Bug #238339 reported by Pjotr12345
4
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

In Ubuntu 8.04 Hardy Heron there is a new phenomenon. Suddenly, after a kernel update, I am asked what to do with the old menu.lst. The wrong choice is offered by default: namely to keep the old menu.lst. That is very wrong, because then the new kernel isn't added to the menu.lst.

The default choice should be, that the new menu.lst from the package manager will be used. Now I have to correct the choice manually. I am an experienced user and am able to understand what I need to do. But beginners will almost certainly be confused and go along with the offered wrong default choice.

Please make the right choice the default choice.

Revision history for this message
Michael Rooney (mrooney) wrote :

Hi Pjotr12345, thanks for using Ubuntu and contributing by filing this report! Note that you are only asked what to do if you have a modified menu.lst, so an inexperienced user is unlikely to encounter this. This behavior is much improved over the previous behavior of always overwriting your previous manual changes each time without even asking or mentioning. The logic is that anyone who edits their menu.lst is able to make the right choice for themselves, as you did.

However, I agree that keeping the old menu.lst is a strange default for the reason you say, but again, if you are editing your menu.lst you should understand what you are doing to it, and therefore be able to understand if you want to keep those changes or not.

If your argument is that beginners will be confused I think it is invalid since beginners are not faced with this dialog. Please correct me if I am wrong.

Revision history for this message
Michael Rooney (mrooney) wrote :

Please see https://wiki.ubuntu.com/GrubConflictDetection for more information.

Revision history for this message
Pjotr12345 (computertip) wrote :

Unfortunately, many beginners do change their menu.lst, namely by installing and using startupmanager. They set Windows as default boot option....

Furthermore, the only change that a kernel update makes to the menu.lst, is rewriting the Automagic part of the menu.lst. Manual changes to the menu.lst apply (or should apply) only to the part that is not automagic and are therefore not affected.

So please, make the default choice the right choice.... I fear that many people are now using outdated kernels without being aware of that.

Revision history for this message
Michael Rooney (mrooney) wrote :

Thanks for informing me of this Pjotr. So you are saying users can easily edit their menu.lst without ever seeing it or being familiar with it? It looks like startupmanager is a supported ubuntu package (in universe) so we should probably be more friendly to this.

But the issue is if we make using the new one the default, don't these new users lose all their changes? This is probably more frustrating to the user. Ideally merging works well and is the default option, don't you think?

Revision history for this message
Pjotr12345 (computertip) wrote :

Thanks for discussing this with me. Well, there are two reasons why I'm not happy with the new system:

1. Making sure that Ubuntu users normally use the latest kernel is absolutely essential for security. That should be the number 1 priority: an outdated kernel could be a security risk.

2. I really can't see the advantage of the new system with the default choice of the old menu.lst.
Like I said, a kernel update only rewrites the Automagic part of the menu.lst, not the entire menu.lst.

As you know, the automagic part starts with these lines:

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

and ends with this line:
### END DEBIAN AUTOMAGIC KERNELS LIST

Which means that timeout, hidden menu, pretty colours and even the Default options aren't changed by a kernel update that adds the new boot lines for the new kernel. So there should arise no discomfort for beginners who use startupmanager, when the new kernel lines are added.

Using startupmanager is a very popular tip on the Dutch Ubuntu forum, and I presume on the English one as well. Because most beginners want to have Windows as default operating system (they get over it, but that takes some time....).

Revision history for this message
Steve Langasek (vorlon) wrote :

Pjotr,

Great care was taken during the implementation to ensure that the prompt is only shown to the user when there is a conflict *in* the autogenerated section of the menu.lst file. If you received this prompt, it's precisely because you have made some changes (using a tool, or by hand) to this section of your menu.lst, and update-grub cannot automatically insert the entry for the new kernel without also destructively overwriting your local changes.

Two of the chief reasons for such conflicts historically are that a user has modified their boot device setting manually without updating the "magic" variable in menu.lst, or that a user has added a completely different boot option within the automanaged block. Doing either of these things is a mistake from the standpoint of the update-grub model, but they're both very common mistakes; and overwriting menu.lst automatically in these cases will either leave the system unbootable, or change the default boot order of the system.

Therefore, leaving the existing boot section alone is the correct default option when a conflict is encountered. Indeed, none of the available options are great defaults, and this is really a stopgap measure until grub2 is ready with a richer config file format that doesn't require the use of magic config sections; but within those constraints, the current implementation functions as intended.

Not getting kernel security fixes if the user chooses the default option is a valid concern, but one that is nevertheless outweighed by the risk of leaving the system unbootable on upgrade.

In any event, if users are seeing this prompt as a result of using startupmanager, then a high-priority task needs to be opened on startupmanager to get *that* tool fixed.

Changed in grub:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.