Thank you for taking the time to report this bug and help to improve
Ubuntu.

> The fallback behaviour on not finding the markers (which isn't there...)
> is kinda harsh: you end up with a semi-empty menu.lst not containing any
> kernels;

That's not accurate; update-grub uses the same markers when inserting
the output from ucf back into the menu.lst as it sed when extracting
them, so if the markers are not found, the menu.lst won't be changed at
all.  If your menu.lst is "semi-empty", it's because that's what you put
there, not because update-grub removed anything.

> while the update-grub tool tells me it has found and correctly
> installed those kernels in the file (which is obviously not true).

What update-grub actually says is:

 Found kernel: /vmlinuz-$version
 [repeat]

followed by:

 Updating /boot/grub/menu.lst ... done

Both of these are true statements, but they don't imply that the named
kernel has been *added* to menu.lst, it only says that it's been found.

At any rate, the solution to all of this is to get rid of update-grub
and menu.lst entirely, because there's no way we can ever get automatic
updating of menu.lst 100% right, and the current behavior is the one we
want - to be deliberately cautious about not overwriting users' local
changes.  And getting rid of menu.lst is being done for karmic, by
switching to grub2 as the default bootloader on new installs; so there's
nothing further to be done here.

** Changed in: grub (Ubuntu)
       Status: New => Invalid

-- 
Update-grub installs empty menu.lst when marker lines are not found
https://bugs.launchpad.net/bugs/453154
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to