Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10

[Jean-Baptiste Lallement]

Test upgrade from 10.04.1 to 10.10:
1. Install Wubi Desktop AMD64 10.04.1
2. apt-get update; apt-get dist-upgrade
3. Restart
4. update-manager -d
5. Upgrade to 10.10
6. Restart

Select 'Ubuntu' in the NTLoader menu

Result:
The following lines are printed on the screen:
  error: unknown command 'loadfont'
 error: file not found.
 error: file not found.
 error: file not found.
 error: file not found.
 error: file not found.
 error: unknown terminal 'gfxterm'
 .
 error: file not found

 then the system restarts (soft reset)

This is reproducible on AMD64 and i386

[Jean-Baptiste Lallement (jibel)]

lscpi -vv of the machine with the problem

[Jean-Baptiste Lallement (jibel)]

dmesg of the machine with the issue.

[Jean-Baptiste Lallement (jibel)]

dist-upgrade logs

[Colin Watson (cjwatson)]

I'm attempting to reproduce here.

[Colin Watson (cjwatson)]

My Wubi system, upgraded using the same procedure (except with the assistance of a local mirror to speed things up) boots just fine.

[Jean-Baptiste Lallement (jibel)]

another user is reporting the same problem in bug 651325 comment #12

[bcbc (bcbc)]

I ran the upgrade Jean-Baptiste is referring to. I don't get any error messages - it just reboots when I select Ubuntu. The upgrade itself appeared successful.

I should mention that I was using the cdromupgrade from the alternate cd (mainly to save time). I'll run some more upgrade tests tonight and see whether I can reproduce.

I am curious as to why wubildr would reboot without displaying any errors. I've seen a few of these reported on ubuntuforums in the past week for users running 10.04 as well - so not sure whether this is even related to 10.10. In some cases users reported seeing the loadfont error, but in others it just reboots. Any tips on fixing or debugging this would be appreciated.

[bcbc (bcbc)]

The loadfont issue is fixable by editing the grub.cfg and commenting out these lines. http://ubuntuforums.org/showthread.php?t=1585673

The straight reboot that I am seeing is more difficult. I tried chrooting into the wubi and running update-grub (this used to work) but now gives:
Generating grub.cfg ...
/usr/sbin/grub-probe: error: cannot stat `/media/PRESARIO/ubuntu/disks/root.disk'.

If you try and run grub-install (to update the wubildr) in chroot, the lupin override doesn't work.

So, I think that this install is toast. The last test I could do is install a fresh maverick wubi and copy over my root.disk to see if the upgrade worked - but this is a time-consuming test and not sure I'll bother. I try some fresh upgrades instead.

Again, any tips in how to debug or fix the automatic reboot would be great.

[bcbc (bcbc)]

Workaround. I deleted everything in grub.cfg except the following:
bcbc@ubuntu:~$ cat /boot/grub/grub.cfg
menuentry "Ubuntu, Linux 2.6.35-22-generic" {
 insmod part_msdos
 insmod ntfs
 set root='(hd0,msdos2)'
 search --no-floppy --fs-uuid --set ea5cc2095cc1d10d
 loopback loop0 /ubuntu/disks/root.disk
 set root=(loop0)
 linux /boot/vmlinuz-2.6.35-22-generic root=/dev/sda2 loop=/ubuntu/disks/root.disk ro quiet splash
 initrd /boot/initrd.img-2.6.35-22-generic
}
bcbc@ubuntu:~$

It popped up the menu, and then booted successfully. So that's interesting.

I guess I'll try update-grub now and see what gives.

[bcbc (bcbc)]

update-grub causes the same problem (computer reboots).

Running "grub-install /dev/sda2" is successful and updates wubildr, but doesn't help.

I noticed in fresh installs of maverick from bug 600578 there is a new wubildr-bootstrap.cfg file which is not present in /ubuntu/winboot after the upgrade. Could this have something to do with it?

[bcbc (bcbc)]

Just completed a successful wubi upgrade from 10.04.1 to 10.10 on a different computer using the cdromupgrade on the alternate cd. (Exact same method as the computer with the problem) So I'll have to go back and try the other computer again when I get the chance.

[Jeff Lane  (bladernr)]

I can confirm this as well on 64bit... installed 10.04.1 64bit to an Athlon II system via wubi, then upgraded to Maverick. I do not get the soft reboots that jibel is seeing, but I am seeing the same messages noted in the original description, and then a system lockup. I have a feeling that my system not rebooting is more just an effect of how the hardware is handing the hang.

In any case, with the exception of the system resetting itself (which in my experience is not that unusual), I'm seeing the same problem here.

[Jean-Baptiste Lallement (jibel)]

I confirm the problem using the same scenario on an eeepc 1015PE tested with ubuntu-10.10-desktop-i386 on Windows 7.
That's a completely different hardware from the first system which is a DELL Optiplex GX620 with Windows XP.

Installing directly maverick (instead of upgrading) works perfectly.

The common denominator is that the systems are both dual boot Ubuntu/Windows, so the boot sequence is Grub / NTLoader / Grub.

[bcbc (bcbc)]

The version of grub at boot (i.e. wubildr) is 1.98-1ubuntu6 on the machine that I am having problems with. The version of grub once the wubi is booted (using grub-install -v) is 1.98+20100804-5ubuntu2.

The machine where the upgrade worked has a grub version of 1.98+20100804-5ubuntu2 at boot. This is obviously the difference.

Both of these machines are dual boots without wubi - i.e. both boot from grub -> XP windows boot manager -> grub. The versions of grub from the MBR on the first machine (problem one) is 1.98-1ubuntu7 and it boots Lucid. The first one is 1.98+20100804-4ubuntu4 and it boots karmic. I tend to use the karmic machine to test maverick on an external so it's probably at some point I installed the grub bootloader from maverick and pointed it to karmic.

But I think this seems to be the likely problem. The grub.cfg contains commands that are incompatible with the bootloader. I deleted all the functions e.g. load_video, recordfail, and something else, and now it seems to work ok. But anytime I run an update it will break.

As I noted earlier there are a bunch of users on 10.04 reporting the same issues on a normal 10.04 update. So this is not unique to maverick. Basically, the fix could be force installing an earlier version of grub-pc on wubi?? Or a setting to force grub to generate a backward compatible grub.cfg.

[Jeff Lane  (bladernr)]

I'm pretty sure the Grub -> NT Loader -> Grub setup is a red herring though... My failing system is not a dual boot setup, so it's just NT Loader -> Grub. Unfortunately, I am not able to catch it and in /ubuntu/disks/boot/grub there is nothing (no grub.cfg) but to be honest, I don't know enough about how wubi works and where it points NTLoader to find and launch grub to really diagnose beyond this at this point.

I can imagine that updating grub during the Lucid -> Maverick upgrade could be the cause of this. If I get time, I'll see if I can rescue and get into the disk image for my wubi install and see what I can learn.

[bcbc (bcbc)]

@Jeff, /ubuntu/disks/boot/ is empty for wubi installs with grub2. you have to loop mount the root.disk to find it. The only fix I know of to get wubi booting in your case is to boot from a live CD, loop mount the root.disk and hand edit the grub.cfg.

[bcbc (bcbc)]

I reinstalled 10.04.1 on my faulty machine, did an offline upgrade using the latest maverick alternate .iso and it works fine. Not exactly the same way I ran the upgrade before but close enough. The grub menu still shows 1.98-1ubuntu6 (as it did when I installed 10.04.1), the grub.cfg also looks the same, yet it now boots fine.

So... basically I have absolutely no idea what was causing the reboot issue.

[Jean-Baptiste Lallement (jibel)]

I did a fresh install on the exact same system (the notebook) and diffed both grub.cfg .
If I replace the grub.cfg from the failed upgrade by the one from the fresh install then it boots fine. So this looks like something with the way grub.cfg is generated during the upgrade.

Here are the 2 .cfg generated during upgrade and install.

[Colin Watson (cjwatson)]

revno: 197
fixes bug(s): https://launchpad.net/bugs/653134
committer: Colin Watson <email address hidden>
branch nick: trunk
timestamp: Mon 2010-10-04 16:47:17 +0100
message:
  Add the font, gfxterm, and gettext modules to the wubildr image, to
  support our default configuration file (LP: #653134).

(This part is for initial installation of 10.10; a lupin change will account for upgrades.)

[requestedRerun (josh-sender)]

Jean-Baptiste Lallement, how does someone change the grub.cfg when you can't boot into ubuntu?

[delance (olivier-delance)]

You reinstall Grub from Live CD.
https://help.ubuntu.com/community/Grub2#Reinstalling%20from%20LiveCD

[Launchpad Janitor (janitor)]

This bug was fixed in the package lupin - 0.32

---------------
lupin (0.32) maverick; urgency=low

  * Add the font, gfxterm, and gettext modules to the wubildr image, to
    support our default configuration file (LP: #653134).
 -- Colin Watson <email address hidden> Mon, 04 Oct 2010 16:40:23 +0100

[bcbc (bcbc)]

@requestedRerun, see the https://wiki.ubuntu.com/WubiGuide on how to loop mount a wubi root.disk. (Section 15. How can I access my Wubi install and repair my install if it won't boot?)

[bcbc (bcbc)]

@Colin, what about the 10.04.1 users having the same problem? Is the fix to run "grub-install /dev/sdaY" to update the wubildr? If that is the case, how do you fix it if the wubi is installed to a partition other than windows. At the moment I am giving them the workaround but no fix.

Please advise
Thanks

[bcbc (bcbc)]

I just ran updates, picked up the lupin fix, but system still won't boot.

[Jean-Baptiste Lallement (jibel)]

I'm reopening the report because after a new upgrade I still have the problem.

[Jean-Baptiste Lallement (jibel)]

I've narrowed down things a bit. In the "bad" configuration file, if I comment the 2 lines:
loopback loop0 /ubuntu/disks/root.disk

The grub menu loads correctly when I select "Ubuntu" at the NTloader menu, then I can load Ubuntu from this menu.

I also need to change lang=fr to lang=en because the system locks up when ubuntu starts to load.

[Colin Watson (cjwatson)]

@bcbc: we'll have to release-note that you simply can't upgrade if wubi is installed to a partition other than Windows. There's no fix for that right now and it's not even clear to me how it could be fixed.

[Jeff Lane  (bladernr)]

Recreated this today with 10.10 using essentially the same steps Jean-Baptiste used with one exception (I used do-release-upgrade -d instead of Update Manager).

After upgrading, I get the same issue, though on my system (a compaq presario w. Athlon II) I just get a hard lock, not a reset. but I get exactly the same messages and fail point.

[Jean-Baptiste Lallement (jibel)]

I conform that in my case the problem is the line "loopback loop0 /ubuntu/disks/root.disk"
I have another system where the system does not reboot before the grub menu and I can edit the entries.
After an upgrade if I boot 'Ubuntu' the there's a soft reset, but if I edit the menu entry and remove that line, then it boots normally.

[bcbc (bcbc)]

@Colin,
I don't really understand enough about what you are trying to accomplish... is it that you have to update the wubildr? I ask because I've never seen wubildr updated by a grub-pc update on any wubi install I've had, despite the fact that grub-install has the ability to do this.

If the problem is that you need to find /host/wubildr to identify a wubi install, why don't you instead use /host/ubuntu/winboot/wubildr because this is always present on any wubi install - i.e. change /usr/share/lupin-support/grub-mkimage
Note if you do need to update wubildr it could always update the /winboot copy if there is no /host/wubildr and then just prompt a user to boot into windows and copy \ubuntu\winboot\wubildr to c:\wubildr. It's a bit cheesy, but it's better than leaving a wubi install broken. The only alternative would be to iterate through all partitions and mount and update any /wubildr it finds - but this might be considered too invasive.

[Colin Watson (cjwatson)]

Yes, you have to update wubildr. The fact that it wasn't updated is why wubi upgrades have often been broken!

Updating /host/ubuntu/winboot/wubildr would be useless since that's not what actually gets used. It's a temporary file which is only left around by mistake.

[Colin Watson (cjwatson)]

(And BTW, on my simple wubi test upgrades, wubildr gets updated.)

[bcbc (bcbc)]

@Colin, OK thanks for the info. FYI on the one broken upgrade to 10.10 I updated the wubildr and regenerated grub.cfg but it then gave me a different error: invalid mode.

I still think it's worthwhile to put in some sort of workaround to preventing problems for wubi installs to a different partition until a real fix can be delivered e.g. overwriting the MBR. Even if it can't fix the wubildr update issue.

[bcbc (bcbc)]

Any update on this?

Some users reported copying the wubildr from the c:\ubuntu\winboot\ directory over c:\wubildr fixed the problem for them - which doesn't make much sense to me - but I've seen 3 comments stating that this worked. My own broken wubi install is still the same (error: no suitable mode).
Others are applying the workaround to loop mount the root.disk and edit the grub.cfg. But obviously this is a pain and will have to be repeated after each kernel update.

[bcbc (bcbc)]

well blow me down, I just copied my old \ubuntu\winboot\wubildr and it worked. haha. I'd love to hear an explanation.

[Chris Whitney (cwhitney24)]

I could not get mine to work. I must have screwed something up when trying cause I lost all of my windows vista. Its all gone, my files, itunes and everything. But now I have the new 10.10. I loaded my 10.04 live back on the computer, then upgraded from the update manager like I did the first time but it worked this time.
Sent via BlackBerry by AT&T

-----Original Message-----
From: bcbc <email address hidden>
Sender: <email address hidden>
Date: Thu, 14 Oct 2010 02:13:35
To: <email address hidden>
Reply-To: Bug 653134 <email address hidden>
Subject: [Bug 653134] Re: Can't boot Ubuntu after an upgrade from 10.04.1 to
 10.10

Any update on this?

Some users reported copying the wubildr from the c:\ubuntu\winboot\ directory over c:\wubildr fixed the problem for them - which doesn't make much sense to me - but I've seen 3 comments stating that this worked. My own broken wubi install is still the same (error: no suitable mode).
Others are applying the workaround to loop mount the root.disk and edit the grub.cfg. But obviously this is a pain and will have to be repeated after each kernel update.

--
Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10
https://bugs.launchpad.net/bugs/653134
You received this bug notification because you are a direct subscriber
of the bug.

Status in Ubuntu Release Notes: Fix Released
Status in Wubi, Windows Ubuntu Installer: Fix Released
Status in “lupin” package in Ubuntu: Triaged
Status in “lupin” source package in Maverick: Triaged

Bug description:
Test upgrade from 10.04.1 to 10.10:
1. Install Wubi Desktop AMD64 10.04.1
2. apt-get update; apt-get dist-upgrade
3. Restart
4. update-manager -d
5. Upgrade to 10.10
6. Restart

Select 'Ubuntu' in the NTLoader menu

Result:
The following lines are printed on the screen:
  error: unknown command 'loadfont'
 error: file not found.
 error: file not found.
 error: file not found.
 error: file not found.
 error: file not found.
 error: unknown terminal 'gfxterm'
 .
 error: file not found

 then the system restarts (soft reset)

This is reproducible on AMD64 and i386

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/653134/+subscribe

[Sébastien GRIPON (sebastien-gripon)]

Same for me, I just copy my old wubildr* files and it worked like a charm.

Would it be possible to have a special grub package for wubi install (wubi-grub) that do not always break wubi installation?

[leightonn (leightonn)]

Copied wubildr from c:\ubuntu\winboot to c:\ and grub now loads. Now getting "error: You need to load the kernel first"

[bcbc (bcbc)]

@colin,

I've noticed cases where grub is being installed to windows partitions again. Not sure if related to the current wubi probs but thought I'd mention it. It's a little different than the old one that used to refer to partition #256. e.g. http://ubuntuforums.org/showthread.php?t=1603958

Extracts from bootinfoscript (fyi /dev/sda is a USB stick):
=> Grub 2 is installed in the MBR of /dev/sdb and looks on the same drive in
    partition #5 for /boot/grub.
...

sdb5: _________________________________________________________________________

    File system: ntfs
    Boot sector type: Grub 2
    Boot sector info: Grub 2 is installed in the boot sector of sdb5 and
                       looks at sector 296660197 of the same hard drive for
                       core.img, but core.img can not be found at this
                       location. According to the info in the boot sector,
                       sdb5 starts at sector 63.
    Operating System:
    Boot files/dirs: /ubuntu/winboot/wubildr.mbr /ubuntu/winboot/wubildr
                       /ubuntu/disks/root.disk /ubuntu/disks/swap.disk
                       /boot/grub/core.img

sdb5/Wubi: _________________________________________________________________________

    File system: ext4
    Boot sector type: Grub 2
    Boot sector info: Grub 2 is installed in the boot sector of sdb5/Wubi
                       and looks at sector 21424016 of the same hard drive
                       for core.img, but core.img can not be found at this
                       location.
    Operating System: Ubuntu 10.10
    Boot files/dirs: /boot/grub/grub.cfg /etc/fstab /boot/grub/core.img

[bcbc (bcbc)]

@Colin,
So I've been running maverick with the 'fix' (copying the wubildr out of winboot) and made a few changes (not the least of which is moving to Natty). I noticed the "invalid mode" command flashing by since then, but still worked.
But then I removed the old maverick kernel, regenerating grub.cfg in the process, and this morning the computer failed to boot again, dropping at the grub prompt.

So long story. Basically I've seen other users on the forums whose maverick has been working and then suddenly: grub prompt. Which points to lupin destroying wubildr, even on 10.10 installs. So I change grub-mkimage in lupin to revert back to the last version (just removed those 3 additional modules), ran 'grub-install /dev/sdaY' and...
it works again.

So, my point is - it's been 3 weeks since release. There have been many affected users on the forums. Is it possible to just revert the lupin change and prevent this problem from reoccurring?

Thanks

PS clearly my tests are not comprehensive, if you need some additional testing to confirm this on, say, a fresh 10.10 install, let me know. I just think the change is fairly minor and, it's pretty clear the new lupin is breaking wubildr, so... it makes sense to me ;)

[bcbc (bcbc)]

@Colin,
Confirmed this fix... I changed grub-mkimage back to original, ran "grub-install /dev/sdaY". Reboot, still worked but now I am seeing the "No suitable mode found" messages flash by. Then I run "sudo update-grub" and reboot.... grub prompt.

So, updating wubildr followed by a regeneration of grub will do it.

Then I reapplied the fix, ran "grub-install /dev/sdaY" again - and it works fine again.

So the modules in my /usr/share/lupin-support/grub-mkimage looks like this now...
# Watch the modules order!
modules=" \
    loadenv biosdisk part_msdos part_gpt fat ntfs ext2 ntfscomp iso9660 loopback \
    search linux boot minicmd cat cpuid chain halt help ls reboot \
    echo test configfile normal sleep memdisk tar"

[bcbc (bcbc)]

@Colin,
I can't break a fresh wubi 10.10 install using the above method (grub-install /dev/sdaY and update-grub). So it appears only upgrades are affected - perhaps missing/corrupt module?

[hpp3 (hpp3)]

Just a confirmation...
Dell 1540 laptop with Ubuntu 10.10 installed via wubi.
Updated packages with the update manager.
On reboot, it dropped to a Grub prompt.
After applying many fix attempts, copying wubildr from C:\ubuntu\winboot to C:\ worked the first time.
Is this a bug in Grub, Wubi or Lupin?

[bcbc (bcbc)]

@hpp3, did you install a fresh wubi 10.10 or upgrade to 10.10 from 10.04?

[a.strotmann (andreas-strotmann)]

I can confirm that upgrading from a fresh wubi install of 10.04.1 to 10.10 currently fails to boot after successful completion, both for 32bit and 64bit installs. Only in the 32bit case do I get a grub prompt - in the 64bit case, the machine just reboots after selecting ubuntu from the list of operating systems.

I can also confirm that this behaviour is fairly recent, and that a previous upgrade from 10.04.1 to 10.10 worked in a 64bit wubi environment. In that case, an automatic security update of 10.10 made it impossible to boot.

[a.strotmann (andreas-strotmann)]

Bug #664106 reports the latter bug, which appears to have the same underlying cause.

[Paul Wowk (madmasta)]

A current work around that works on my system is after it makes it to the grub command prompt... type:

insmod ntfs
set root=(hd0,2)
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)
linux /boot/vmlinuz-2.6.35-22-generic root=/dev/sda2
   loop=/ubuntu/disks/root.disk ro
initrd /boot/initrd.img-2.6.35-22-generic
boot

Change the root=(hd0,2) and root=/dev/sda2 to the correct hard drives and it should boot.

- Paul

[bcbc (bcbc)]

One month since release...

Riddle: what do you call an operating system that won't boot?

[Erno Kuusela (erno-iki)]

Wubi broke on Lucid (but there was a workaround discovered to make it boot agian) and now again Maverick with no end user workable way to restore the system to a usable state.

It's still featured in a prominent place on the Ubuntu install web site ("try from windows") where it will be the first
contact with Ubuntu/Linux for many people considering migration from Windows. Why?

[bcbc (bcbc)]

I installed a fresh 10.10 Maverick using Wubi. Then I went into synaptic and reinstalled grub-pc. This is the diff file from grub.cfg before reinstalling and after.
35,36d34
< insmod vbe
< insmod vga
39,59d36
< insmod part_msdos
< insmod ntfs
< set root='(hd0,msdos2)'
< search --no-floppy --fs-uuid --set 80e4e195e4e18daa
< loopback loop0 /ubuntu/disks/root.disk
< set root=(loop0)
< if loadfont /usr/share/grub/unicode.pf2 ; then
< set gfxmode=640x480
< load_video
< insmod gfxterm
< fi
< terminal_output gfxterm
< insmod part_msdos
< insmod ntfs
< set root='(hd0,msdos2)'
< search --no-floppy --fs-uuid --set 80e4e195e4e18daa
< loopback loop0 /ubuntu/disks/root.disk
< set root=(loop0)
< set locale_dir=($root)/boot/grub/locale
< set lang=en
< insmod gettext
140,155d116
< }

So... this is probably the root cause of the issue. I've been seeing reports on ubuntuforums.org that commenting out the loopback lines (the two in the diff shown above) gets wubi booting. But surely the cause is that all these lines are different between the base install, and reinstalling grub-pc i.e. one of the scripts in /etc/grub.d is being changed from the default install.

This is likely also the problem then with the 10.04.1 installs that are breaking.

[bcbc (bcbc)]

Actually there were no differences in /etc/grub.d
There were a lot of differences in /boot/grub (all the .mod files aren't there on a default wubi install, but are added when reinstalling grub-pc).

[bcbc (bcbc)]

Updated to the latest Maverick kernel =====> grub prompt on reboot.

So... conclusion. Updating grub-pc on a wubi install breaks wubi. I will now do a reinstall and diff the entire installation to see what else changes.

[bcbc (bcbc)]

This is the full diff of a new wubi 10.10 install before and after reinstalling grub-pc

[bcbc (bcbc)]

OK I have the permanent fix for 10.10.... Probably works on 10.04.1 too.

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 fresh wubi install)
 cd /boot/grub
sudo rm *.mod
sudo rm *.img
sudo rm *.lst
sudo rm *.o
sudo rm *.pf2
sudo rm -rf locale

This leaves 2 files:
bcbc@ubuntu:/boot/grub$ ls
grub.cfg grubenv

Update the grub.cfg automatically:
sudo update-grub

FIXED!

Not done yet - prevent grub updates from breaking it again:
Go to Synatpic, select packages grub-pc and grub-common, click on Package, Lock Version

For the developers, these are the differences between /boot/grub/ and /usr/lib/grub/i386-pc/ which probably indicate the problem areas --- the locale directory for one.
bcbc@ubuntu:/boot/grub$ diff -r /usr/lib/grub/i386-pc/ /boot/grubbeforetest/
Only in /usr/lib/grub/i386-pc/: build_env.mk
Only in /usr/lib/grub/i386-pc/: config.h
Only in /usr/lib/grub/i386-pc/: g2hdr.bin
Only in /usr/lib/grub/i386-pc/: g2ldr.mbr
Only in /boot/grubbeforetest/: grub.cfg
Only in /boot/grubbeforetest/: grubenv
Only in /usr/lib/grub/i386-pc/: grub_script.tab.h
Only in /boot/grubbeforetest/: locale
Only in /boot/grubbeforetest/: unicode.pf2

[amichair (amichai2)]

My experience, for what it's worth:

A netbook wubi installation of Kubuntu 10.10 (upgraded from 10.04) worked ok, and then broke one day recently (probably after an update). After selecting kubuntu from the Windows XP boot menu, it would momentarily flash the following 3 errors:

error: file not found
error: file not found
error: no suitable mode found

and right after that the screen went blank and system stuck - only a cold boot, with holding the power button down for 5 seconds or so, would get it out of this state.

Copying the "wubildr" file from C:\ubuntu\winboot to C:\ as suggested above (overwriting an existing wubildr in the root directory) fixed the problem.

I don't know if this is a bug in wubi or grub or ubuntu packaging, but a system update that prevents the system from booting is a critical bug, and should be fixed within a couple of days tops from first being reported... not lingering on for weeks or months leaving many users with unusable systems and wasting hours of their time trying to find manual workarounds. Sorry for the rant, but I've suffered another critical bug recently (preventing the mouse from working on a desktop), which has gone unresolved for a couple of months too even though hundreds of reports came in, and probably thousands of affected users have been unable to use their systems. Whomever has a say in it, please try to re-assess ubuntu's priorities...

[bcbc (bcbc)]

The reason these extra files get placed in /boot/grub is that grub-install is called to update the wubildr file, and grub-install calls grub-install.real (for wubi) and that copies the files (in the following code grubdir is /boot/grub and pkglibdir is /usr/lib/grub/<target cpu>/):

for file in ${pkglibdir}/*.mod ${pkglibdir}/*.lst; do
    cp -f $file ${grubdir} || exit 1
done
if [ "${target_cpu}-${platform}" = "i386-pc" ] || [ "${target_cpu}-${platform}" = "sparc64-ieee1275" ] ; then
    for file in ${pkglibdir}/*.img ${pkglibdir}/efiemu??.o; do
 if test -f $file; then
     cp -f $file ${grubdir} || exit 1
 fi
    done
fi

=========================
I suppose an easy temp fix would be to change lupin's grub-install to clean up /boot/grub on the way out.

[a.strotmann (andreas-strotmann)]

This is getting worse before it's (hopefully) getting better. Today, the same problem happened again, but not during an upgrade from Lucid to Maverick, but during a regular update of Lucid to the latest Lucid kernel.

I noticed that there was an update to grub-pc the other day (current version of grub-pc installed on my system, a Wubi install of 10.04.1 with 32bit PAE kernel: 1.98-1ubuntu9). Today, I upgraded to the latest kernel for my system (2.6.32.27.29), and it stopped booting with the same problem as Maverick before.

The work-around above worked to get it running again after loop-mounting the partition into a virtual Ubuntu on the Windows side. No need to run update-grub, though, apparently.

[Elliott kensdale (e-kensdale)]

bcbc and others have advised using synaptics to lock grup-pc and grub-common. I did this - they are still locked (checked after I got back in) but the loadfont problem happened again after my update this morning.
Luckily I have Live Cd and the instructions to comment out the lines but why, if they are locked, does the updater change them?
I have also locked a lupin something.
Not a LInux expert at all but using it instead of Windows XP with wubi - this is annoying and I cannot expect the rest of the family or friends to use Linux if this is going to happen every time.

Anyone got any answers?

[bcbc (bcbc)]

@elliot, locking grub-pc and grub-common works to prevent boot problems caused by updating those packages. e.g. on a fresh install of Wubi. If you've already updated grub-pc or upgraded to 10.10, then the /boot/grub directory contains all the grub modules - and that results in the buggy grub.cfg file. Locking grub-* won't be enough in this case, you also have to clean up /boot/grub (restore it to what it is on a fresh wubi install).
sudo mv /boot/grub /boot/grubold
sudo mkdir /boot/grub
sudo cp /boot/grubold/grubenv /boot/grub/grubenv
sudo update-grub

The details are describe in the Wubi megathread on ubuntuforums.org: http://ubuntuforums.org/showthread.php?t=1639198

[Colin Watson (cjwatson)]

I think this was almost certainly down to the problem I fixed in bug 742967 for Natty (and will backport to Lucid and Maverick shortly), possibly along with contributions from bug 610898 and bug 695290. I'll mark this as a duplicate.