[Hardy 8.04 alpha] update-grub does not write anything

Bug #186412 reported by SK on 2008-01-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Nominated for Hardy by Stanley Sokolow

Bug Description

Binary package hint: grub

As of grub package version 0.97-29ubuntu10 (maybe already one version earlier) the update-grub script does not write any of the detected kernels to the menu.lst file.

Steps to reproduce:
- Back up your menu.lst file.
- Remove your menu.lst file.
- Run sudo update-grub.
- Note the following output (or something simliar):

Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ...

Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst generated for you? (y/N) y
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-2.6.24-5-generic
Found kernel: /boot/vmlinuz-2.6.24-4-generic
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

- Review the newly generated menu.lst file.
- Note that there are no elements in the "AUTOMAGIC KERNEL LIST".

( - Replace the new menu.lst with your backup copy, or you won't be able to boot next time! )

This is a very critical bug because it effectively disables the installation of new kernels through a regular upgrade process!

I am using Hardy 2.6.24-5-generic (because I updated the menu.lst entry manually in order to boot into -5).
I have no idea what kind of information you would need on a report like this, so I am attaching the currently working menu.lst and the one generated by update-grub.
Let me know if you need anything else.

SK (stephantom) wrote :
SK (stephantom) wrote :
description: updated
Stanley Sokolow (overbyte) wrote :

See also bug #186246 which reports that menu.lst in recent Ubuntu i386 desktops installed from daily builds of LiveCD do not have the necessary kernel boot information, just like the "empty" menu.lst file attached to this bug. Bug #186246 may be another consequence of this faulty update-grub command.

SK (stephantom) wrote :

Per Bug #186246 (which has been marked as dup) I set this report to "Confirmed".

Changed in grub:
status: New → Confirmed
SK (stephantom) wrote :

I recall having the problem described in bug #8497 before update-grub stopped working. Might be related?

Stanley Sokolow (overbyte) wrote :

If it's not too late, could you please set this to Importance=High and put it on the milestones for the Alpha-4 release? https://bugs.launchpad.net/ubuntu/+milestone/hardy-alpha-4
It would be far better to delay alpha-4 a little in order to fix this bug so the alpha-4 installations actually produce a system that boots into the kernel, rather than pushing out an alpha-4 release that requires a lot of manual editing to work around this bug. I would say that this bug is a show-stopper for alpha-4.

Steve Langasek (vorlon) wrote :

Confirmed. This bug occurs only when update-grub has previously registered the config with ucf, but /boot/grub/menu.lst is being regenerated from scratch. Fix is in progress.

Changed in grub:
importance: Undecided → High
milestone: none → hardy-alpha-4
status: Confirmed → In Progress
Stanley Sokolow (overbyte) wrote :

Reading bug #8497, I see that bug as a problem with the mapping of hard drives in multi-drive systems, i.e. which drive is the primary boot drive. However, the current bug is not that. Here the menu.lst doesn't list any drive to boot from. My testing system now has only one hard drive and it experiences this bug.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub - 0.97-29ubuntu11

grub (0.97-29ubuntu11) hardy; urgency=low

  * debian/control: point XS-Vcs-Bzr at the Ubuntu repository instead of
    pointing at the Debian repository.
  * debian/update-grub: if menu.lst does not exist at the time update-grub is
    called, the "current" and "proposed" kernel lists should always be
    identical, so set them equal in ucf_update_kernels. This fixes a
    remaining bug where regenerating menu.lst from scratch after it's been
    registered once with ucf would result in an empty kernel list.
    LP: #186412.
  * Add a debconf template so that our ucf prompts don't refer to a filename
    that has no meaning to the user
  * Add Build-Depends on po-debconf for the above, and depend on
    debconf-utils to allow for loading the debconf template from a
    script that is not a package maintainer script.
  * Raise depends to ucf (>= 3.004-0ubuntu2)

 -- Steve Langasek <email address hidden> Mon, 28 Jan 2008 13:11:25 -0800

Changed in grub:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers