update-grub does not update 'default' option when the number of boot options changes

[Vitor Boschi]

When I install a new kernel image using apt, the file menu.lst is changed, but the default option line isn't changed accordingly. As an example, I had the Windows partition as default, but after the update, the default option is the Memory Test utility. All the entries are ok. The only problem is the default selection.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you provide us with the exact command you used to install the new kernel? In addition which version of Ubuntu are you using? Thanks in advance.

[Vitor Boschi (vitorboschi)]

I'm using Ubuntu 6.10. The update was done using the standard auto-updater tool.

[Benoit Malet (benoit-malet)]

Hello !

I also have a similar problem, probably it has the same cause:

I manually edited my menu.lst to open console in framebuffer and I removed the use of splash and quiet (I like to see the lines flying while kernel is booting ;)) ... After kernel update (Ubuntu 6.10, standard updater), grub config comes back to default ...

Ticket #5167 from support seems to have the same cause too, I'll link the support request to this bug ...

I'm available for every info that could be needed.

Regards,
Benoît

[Tsvi Mostovicz (tsvi)]

I opened ticket #5167.
After updating the kernel using adept, the entries in grub for my kernel revert to "root (hd0,8)" Which was correct up until I deleted a couple of partitions (I was quad booting before with fedora and opensuse). Now this line needs to read (hd0,5) which can be edited manually. But apparently there's some config file from the old partition that keeps changing the entry.
Entries changed are only the ones between automagic kernels comment lines.

[Alessandro Pellegrini (alessandro-pellegrini)]

I have been also affected by this bug...
I manually edited (with minor changes) menu.lst and on the next kernel update, menu.lst came back to its original form...

Since the first time, I have manually re-edited menu.lst on each upgrade... It seems like the updater doesn't checks whether menu.lst has been edited...

[Brian Murray (brian-murray)]

Could you please add the full contents of your menu.lst file as attachments to this bug report? Thanks.

[Benoit Malet (benoit-malet)]

Hello !

Here is my menu.lst (see attachment).

Unfortunately I don't have a backup of the former one ...

Regards,
Benoît

[Realtime (peter-icb)]

I have a similar problem.

The update writes hd0,0 instead of hd0,2 in the menu.lst. I have to correct this manually, then it works fine.

I have upgraded to Kubuntu Feisty AMD64 when this happened.

Peter

[santiago (santiagozky)]

I compiled a custom kernel (2.6.21-rcX) using make-kpkg, and then installed the deb files (image and headers). The menu.lst wasnt updated to make the new kernel the default, so I change the file manually. A bit later I had some problems with the kernel so I remove it (using aptitude), and again menu.lst wasnt updated so memorytest became the default.

I think that when a kernel is going to be removed, the system should see which is the default entry in the menu.lst and if the kernel being removed is placed before that entry (or is that entry), the default entry should be decreased in 2 (normal and recovery mode). Or it can decrease the default until another kernel is found if the removed kernel is the default.

[Tsvi Mostovicz (tsvi)]

Problem solved.
After installing a new kernel., dpkg runs update-grub. Read the man page, as seen there, it checks the kernel files under /boot as well as the defaults set up in menu.lst one of them being "groot (hd0,8)" This of course in my case has to be edited to reflect the new partitioning.
What we need is either a code that will double-check the current grub configuration and alert the user to a discrepancy between the currently considered default, and the actual default.
This alert can also be called upon after closing parted. Another option is having a current view of the partitions stored, and checked to see changes weren't made at reboot. (Most partitioning of systems is done while running some kind of livecd so after running parted doesn't really help)

[beerfan (beerfan)]

I just experienced this. Yesterday's (2007-06-09) kernel update replaced my menu.lst with what seems to be the version created on install. I have since upgraded my hard-drive and the root is on a different partition and has a different volume id. After the kernel update all changes were gone and the root was back to hd0,0 with the wrong UUID so I couldn't boot. I have no idea if the correct kernel version is even being loaded now but if it replaced all the options with the install version I'm guessing no.

[beerfan (beerfan)]

I forgot to mention but the above comments are regarding Feisty.

[NiklasW (falken)]

Same issue here (Feisty Fawn), I loose the correct UUID every time grub updates the menu.lst file. This was triggered after I replaced the system disk with another disk... ever since I get into problem with the menu.lst file.

I do not understand the Problem solved quote above, but then again it may be due to my knowlege (or lack of knowlege :) from how grub works. I thing I need to make grub understand what the default value (UUID) should be.

[NiklasW (falken)]

Problem solved (unconfirmed but likely)

in my menu.lst file I had 2 different "kopt" options defined. These referred to my old UUID, one was a general kopt (affecting all changes) and one was just affecting 2.6 versions of kernels.

From my menu.lst:

# kopt=root=UUID=3579f529-ca4f-4243-b6aa-f28797f6a7e6 ro
# kopt_2_6=root=UUID=3579f529-ca4f-4243-b6aa-f28797f6a7e6 ro

I have not confirmed that the issue is solved for me, but I find it likely that it will use the new default UUID the next time and therefore also work.. i hope :)

[Paul Sharp (paul5082)]

From my experience, when a new kernel is updated, it doesn't even update the old menu.lst. It reads kernels installed on the computer & writes a new one with them in the list and the newest on top. I have a computer with 4 hard drives. 1st hdd is Windows XP, 3rd is Ubuntu. The other two (2 & 4) are data hdd's. It keeps writing that the ubuntu partition is on hd1,0, when the previous menu.lst had it correct - hd2,0. It totally removes the Windows addition to the menu. I have to edit the boot line and when in the desktop, I have to make corrections (on every kernel update) to menu.lst to reflect proper options.

I also experienced when I just installed Gutsy 7.10, it didn't even recognize I had Windows on another hard drive, and it also complained that Ubuntu was hd1,0, when it was actually 2,0. I had to edit the line initially to get it to boot.

After a kernel upgrade, it will always require changing menu.lst to reflect proper configuration - NOT really a good option for a newbie (which I'm not). If I was a newbie & had to figure that out, I probably wouldn't consider using it.

If you had one computer, one hard drive, it would be just fine, but that's not always the case.

[Shaved Wookie (shavedwookie)]

Same kind of thing here.

Every time the kernel updates (only as of the last couple of months) it puts my Ubuntu down as hdd(2,0) when it's actually hdd(0,0). Editing the boot line and then menu.lst fix the problem until the next update.

[Upendran (ubuntu-upendran)]

I am facing this problem in all Ubuntu releases. I have two SATA and one IDE hard disks. I use Smart Boot Manager to boot the system for multiple Operating Systems. Grub resides in Ubuntu partition. I found that Grub and Ubuntu installer do not agree about the sequence in which the drives are enumerated. There is a confusion in deciding whether SATA or IDE drives are to be enumerated first. After every kernel upgrade menu.lst file has to be manually edited to correct the problem. I have noticed that Fedora, Suse and Mandrake releases do not have this conflict.

[irwjager (jager49)]

Same thing here.
The kernel updater changed all root entries to 0,0 and completely removed my windows boot option from menu.lst
I too had to manually change the boot line, then menu.lst

[Paul Sharp (paul5082)]

And yet another kernel update which broke menu.lst! I think this ought to be a more prioritized fix. I don't know what needs to be done to correct writing a new menu.lst every time the kernel is updated. but it even takes out the windows portion of menu.lst. That has to be added back as well every time.

[Colin Watson (cjwatson)]

The correct way to edit this file is documented in comments in the file itself. That said, it is a cumbersome and error-prone procedure. The grub-configuration-improvements specification proposes a reasonably straightforward (if not necessarily pretty) approach to protecting users from shooting themselves in the foot here, and this is on the development roadmap for Ubuntu 8.04.

[James Ascroft-Leigh (jwal)]

I suggest that there are actually two issues worth separating in this bug report:

   1. The original post about the default kernel changing away from Windows
   2. The noisier issue about manually editing kernels in the "AUTOMAGIC" section of the file

Both can be fixed by a better understanding of how the update-grub command works. I have read the grub-configuration-improvements specification and it seems to address only problem 2 (though it does so very well).

Returning to problem 1, then.

When the Ubuntu installer detects the Windows operating system it will create extra stanzas in the menu.lst file for it at the bottom of the file under the divider "Other operating systems". Notably these stanzas are placed under the "AUTOMAGIC" section that can dynamically grow new entries as new Ubuntu kernels are installed. If you wish to boot into Windows by default then you can do so by changing the default stanza number but when a new Ubuntu kernel is installed the number for the Windows stanza will change and the default will change.

The simple solution, as I have implemented successfully on my father's computer, is to move the non-Ubuntu stanza that you want as the default above the "AUTOMAGIC" section and set default back to 0.

Hope this helps.

It might be worth detecting this problematic situation and prompting the user at update-grub time too (note added to specification).

[oger000 (oger000-deactivatedaccount)]

That the stanzas between the "### BEGIN AUTOMAGIC KERNELS LIST" and the "### END DEBIAN AUTOMAGIC KERNELS LIST" markers are modified to the will of the installer is something that I expected.
But installing the ubuntu alternate 64 bit version removes all stanzas after the "### END ..." marker without making any backup or anything else to preserve them (vor example make them a comment).

[oger000 (oger000-deactivatedaccount)]

Sorry for this line, but it is not possible to set the "email me about this bug" without writing a comment ;-((((

[nowshining (nowshining)]

gerhard oettl not true,

on the left hand side in the pink box under Actions click the link Entitled Subscribe and on the next page, and click continue. :)

[oger000 (oger000-deactivatedaccount)]

You are right I am new and was too hasty ;-) Thank you for the hint.

I also forgot to mention that there is a comment
"# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST"
in the menu.lst file. I hope this is not only valid for debian but also for ubunto (and other linux distributions using grub).

[Steve Langasek (vorlon)]

The issue with the silent loss of configuration settings when update-grub is run is bug #21412.

This report is about the fact that the 'default' boot option is not updated on upgrade to reflect changes in the number of available boot options. Retitling to reflect this.

[James Westby (james-w)]

Hi,

If you want this behaviour then you can edit
/boot/grub/menu.lst where it says

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

to say

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=true

Should this be enabled by default?

Thanks,

James

[Mikhail Batser (mbatser)]

Well, two years have passed and nothing have been done to make life easier.

As usual, though.

[dino99 (9d9)]

This is no more a supported version; and grub legacy upstream is also stopped, only receiving possible random fixes locally