[Wubi] when updating it advices to install grub on all partitions

Bug #581760 reported by Nicolò Chieffo
This bug affects 5 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Colin Watson
Colin Watson
Colin Watson

Bug Description

Binary package hint: grub2

Yesterday I was updating from karmic to lucid from a WUBI installation.
During the upgrade of grub-pc, an information message appears telling me to choose in which devices grub2 showld be installed.
If you press OK (like a windows user does) everything will work, but if you read the help, you'll see this:
"If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them."

This will for sure destroy everything at the bootloader level!

TEST CASE: Install the original Ubuntu 10.04 LTS release via Wubi. Upgrade grub-pc to version 1.98-1ubuntu7 in lucid-updates (should fail) or to version 1.98-1ubuntu8 which I'll upload to lucid-proposed shortly (should work). The failing case will ask a confusing question and may render the system unbootable. The successful case should work without asking any questions, and on the next boot the version number should match the newly-installed version.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: grub-pc 1.98-1ubuntu6
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Mon May 17 15:39:07 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
SourcePackage: grub2

Revision history for this message
Nicolò Chieffo (yelo3) wrote :
Colin Watson (cjwatson)
summary: - when updating it advices to install grub on all partitions
+ [Wubi] when updating it advices to install grub on all partitions
Changed in grub2 (Ubuntu):
status: New → Triaged
importance: Undecided → High
Colin Watson (cjwatson)
Changed in grub2 (Ubuntu Maverick):
assignee: nobody → Colin Watson (cjwatson)
milestone: none → ubuntu-10.10
status: Triaged → Fix Committed
Colin Watson (cjwatson)
Changed in grub2 (Ubuntu Lucid):
status: New → Triaged
importance: Undecided → High
milestone: none → ubuntu-10.04.2
assignee: nobody → Colin Watson (cjwatson)
Changed in wubi:
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.6 KiB)

This bug was fixed in the package grub2 - 1.98+20100804-5ubuntu1

grub2 (1.98+20100804-5ubuntu1) maverick; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Adjust for default Ubuntu boot options ("quiet splash").
    - Default to hiding the menu; holding down Shift at boot will show it.
    - Set a monochromatic theme for Ubuntu.
    - Apply Ubuntu GRUB Legacy changes to legacy update-grub script: title,
      recovery mode, quiet option, tweak how memtest86+ is displayed, and
      use UUIDs where appropriate.
    - Fix backslash-escaping in merge_debconf_into_conf.
    - Remove "GNU/Linux" from default distributor string.
    - Add crashkernel= options if kdump and makedumpfile are available.
    - If other operating systems are installed, then automatically unhide
      the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus
      if available to check whether Shift is pressed. If it is, show the
      menu, otherwise boot immediately. If keystatus is not available, then
      fall back to a short delay interruptible with Escape.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Don't display introductory message about line editing unless we're
      actually offering a shell prompt. Don't clear the screen just before
      booting if we never drew the menu in the first place.
    - Remove some verbose messages printed before reading the configuration
    - Suppress progress messages as the kernel and initrd load for
      non-recovery kernel menu entries.
    - Change prepare_grub_to_access_device to handle filesystems
      loop-mounted on file images.
    - Ignore devices loop-mounted from files in 10_linux.
    - Show the boot menu if the previous boot failed, that is if it failed
      to get to the end of one of the normal runlevels.
    - Handle RAID devices containing virtio components.
    - Don't generate /boot/grub/device.map during grub-install or
      grub-mkconfig by default.
    - Adjust upgrade version checks for Ubuntu.
    - Don't display "GRUB loading" unless Shift is held down.
    - Adjust versions of grub-doc and grub-legacy-doc conflicts to tolerate
      our backport of the grub-doc split.
    - Fix LVM/RAID probing in the absence of /boot/grub/device.map.
    - Look for .mo files in /usr/share/locale-langpack as well, in
    - Make sure GRUB_TIMEOUT isn't quoted unnecessarily.
    - Probe all devices in 'grub-probe --target=drive' if
      /boot/grub/device.map is missing.
    - Adjust hostdisk id for hard disks, allowing grub-setup to use its
      standard workaround for broken BIOSes.
    - Build-depend on qemu-kvm rather than qemu-system for grub-pc tests.
    - Use qemu rather than qemu-system-i386.
    - Extend the EFI version of grub-install to be able to install into an
      EFI System Partition mounted on /boot/efi in a location that complies
      with the EFI specification.
    - Upgrade the installed core image when upgrading grub-efi-ia32 or
      grub-efi-amd64, although only if /boot/efi/EFI/ubuntu already exists.
    - Make grub-efi-ia32 and grub-efi-amd64 depend on efibootmgr so that


Changed in grub2 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Colin Watson (cjwatson)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted grub2 into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in grub2 (Ubuntu Lucid):
status: Triaged → Fix Committed
tags: added: verification-needed
Revision history for this message
Scott Moser (smoser) wrote :

I tried to verify this by
a.) installing wubi from 10.04 (not 10.04.1 ISO)
    d044a2a0c8103fc3e5b7e18b0f7de1c8 ubuntu-10.04-desktop-i386.iso
b.) add -proposed
c.) apt-get update && apt-get install grub-pc

I noticed in the upgrade console messages that i was replacing '1.98-1ubuntu7'. Though I'm not sure how that would have occurred. I checked the media I did the install from and it said:
$ grep grub casper/filesystem.manifest-*
casper/filesystem.manifest:grub-common 1.98-1ubuntu5
casper/filesystem.manifest:grub-pc 1.98-1ubuntu5
casper/filesystem.manifest-desktop:grub-common 1.98-1ubuntu5
casper/filesystem.manifest-desktop:grub-pc 1.98-1ubuntu5

So I'm not sure if this qualifies as a verification or not, since somehow 1.98-1ubuntu7 got installed and I didn't see any scary messages.

Revision history for this message
Scott Moser (smoser) wrote :

I tried above again, this time disconnecting the network cord.
- Installed from the same media mentioned.
- rebooted, hitting escape at the grub loader after windows loader and verified it was 1.98-1ubuntu5
- let the install run to completion
- reboot, verify still at 1.98-1ubuntu5
- did not add -proposed, 'apt-get install grub-pc' and saw confusing prompt (installing 1ubuntu7)

Then, I uninstalled wubi and repeated above except for this time *did* add -proposed.
I did *not* see the confusing prompt going from 1.98-1ubuntu5 to 1.98-1ubuntu8, verified that on reboot 1.98-1ubuntu8 was installed, and that reboot succeeded.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Colin Watson (cjwatson) wrote :

Sounds good to me. Thanks!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.98-1ubuntu8

grub2 (1.98-1ubuntu8) lucid-proposed; urgency=low

  * On Wubi, don't ask for an install device, but just update wubildr using
    the diverted grub-install (LP: #581760).
 -- Colin Watson <email address hidden> Thu, 23 Sep 2010 14:26:00 +0100

Changed in grub2 (Ubuntu Lucid):
status: Fix Committed → Fix Released
Revision history for this message
bcbc (bcbc) wrote :

pity about users who didn't install on the same partition as windows. let the borkage commence. is it me or does it appear 1 test case was enough to verify?

Revision history for this message
bcbc (bcbc) wrote :

Even for users who installed on the same partition as windows, the wubildr update is failing. So we have wubi users who installed on the same partition can't start Ubuntu. And wubi users who installed on a different partition installing grub and not booting either windows or ubuntu.
And all this for an update that really does nothing.

For instance a message like the following:

"Hi all,

Just updated using the update manager and unfortunately can no longer load wubi. Get an error message saying:

error: unknown command 'loadfont'
error: file not found

Seems people in the past have had problems with this happening to wubi. Not a huge deal since I have everything backed up but just want people to be aware of this as I don't think it will be just me?

Going to partition and make a proper ubuntu install now"

Revision history for this message
bcbc (bcbc) wrote :

1. Install Wubi Ubuntu 10.04.1 on same partition as Windows
2. Run all updates listed by update manager (210MB) including grub-pc and grub-common
3. Reboot.
Result, Ubuntu does not boot. Selecting ubuntu from the Windows boot manager causes computer to reboot.

The only workaround I can find is to loop mount the root.disk and edit the grub.cfg manually. Replacing the updated wubildr with the old one doesn't help at all.

Again, I have to ask - since this update is specific to Wubi... did anyone actually test it on 10.04.1? And if it isn't actually achieving anything... why?

Revision history for this message
Eric Cunningham (beagle4321-2000) wrote :

I don't understand how to do your instructions: I need a step by step fix to this problem:
" Upgrade grub-pc to version 1.98-1ubuntu7 in lucid-updates (should fail) or to version 1.98-1ubuntu8 which I'll upload to lucid-proposed shortly (should work)."


Revision history for this message
bcbc (bcbc) wrote :

Eric this fix has already been released . If it has broken your install the fix involves getting Wubi to boot, and then manually repairing it.

At ubuntuforums.org we are working on a single thread to explain all this in a clear and concise way, but in the meantime, you can do this.

Boot a live CD, identify your windows partition that contains the root.disk (this example assumes /dev/sda1), and then edit grub.cfg as follows:
sudo mkdir /media/win
sudo mount /dev/sda1 /media/win
sudo mount -o loop /media/win/ubuntu/disks/root.disk /mnt
sudo cp /mnt/boot/grub/grub.cfg /mnt/boot/grub/grub.cfg.copy
sudo chmod +w /mnt/boot/grub/grub.cfg
gksu gedit /mnt/boot/grub/grub.cfg

Then delete all lines up to but not including the first line that starts with 'menuentry'. Save and reboot. This should get you back into the Wubi install.

You then need to make sure the problem doesn't happen again (as grub.cfg gets automatically regenerated).
First back up /boot/grub
sudo cp -r /boot/grub /boot/grubbackup

Then delete all the stuff in /boot/grub that isn't supposed to be there (everything added after a fresh wubi install) - take care with the rm and rm -rf commands:
cd /boot/grub
sudo rm *.mod
sudo rm *.img
sudo rm *.lst
sudo rm *.o
sudo rm *.pf2
sudo rm -rf locale

This leaves just 2 files in /boot/grub:
grub.cfg grubenv

Then update the grub.cfg automatically:
sudo update-grub

To prevent grub updates from breaking it again:
Go to Synaptic, select packages grub-pc and grub-common, click on Package, Lock Version

Revision history for this message
Kasper Brink (k-brink) wrote :

After the recent grub update (to version 1.98-1ubuntu8), my Ubuntu 10.04.1 install (using Wubi on Windows 7) failed to boot. The system rebooted almost immediately after choosing "Ubuntu" in the Windows boot manager. Booting Windows was unaffected.

Editing /boot/grub/grub.cfg with a live cd (see comment #12), I removed the following lines to get the system to boot again:
  if loadfont /usr/share/grub/unicode.pf2 ; then
     set gfxmode=640x480
     insmod gfxterm
     insmod vbe
     if terminal_output gfxterm ; then true ; else
       # For backward compatibility with versions of terminal.mod that don't
       # understand terminal_output
       terminal gfxterm
  insmod gettext

To ensure that the offending lines are not re-added when grub.cfg is regenerated, I uncommented the line:


in /etc/default/grub, and ran update-grub. The resulting grub.cfg works for me.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

@bcbc : this bug is closed so maybe nobody reads it anymore... maybe you should open a new bug report (and link it here) to explain the "new" problem brought by this fix ?

tags: added: testcase
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers