grub-pc upgrade renders computer unbootable when Wubi is installed to partition other than Windows

Can someone please clarify what the fix should be. It's easy enough to reinstall the windows bootloader to get windows booting, but in some cases the ubuntu will still not boot. My suspicion is that the wubildr needs to be updated to be compatible with the latest grub-pc version, but a) it's just a theory and b) how do we get an updated wubildr to fix this?

There are users out there who've lost their entire wubi install due to not understanding what it means to reinstall or where their data is stored.

I finally got to test the grub-pc update. The wubildr file does not get updated, so that theory was incorrect. The grub-install screen showed a checkbox 'skip installing grub'. If you click forward you now go back to the 'select a device to install grub' screen (previously you had to check the 'skip' box to proceed). So this might just be user confusion. However, no user has confirmed seeing this screen (and checking on []/dev/sda) - so really not certain if this is the case - I haven't tested it on a wubi install to a separate partition and so far most of the problem cases indicated a separate partition install.

Here's a few more affected users...
http://ubuntuforums.org/showthread.php?t=1541206
http://ubuntuforums.org/showthread.php?t=1542128
http://ubuntuforums.org/showthread.php?t=1541155
http://ubuntuforums.org/showthread.php?t=1542020
http://ubuntuforums.org/showthread.php?t=1542719
http://ubuntuforums.org/showthread.php?t=1542770

Yes, thanks. The only temporary fix I have would be to boot from CD-ROM, and press ESC, and select the boot from first hard drive option to activate the Windows Bootloader to get into either Ubuntu or Windows 7. Not the best way to boot up a PC, but it's the only way until a true fix comes about.

I had what is perhaps a silly thought about this. Since I haven't been able to really do a full Wubi install recently I'm just working from memory but I think Wubi performs a "post-install" process and I wonder if it wouldn't be possible for the Wubi devs to have the packages "grub", "grub-pc", and "grub-common" locked during that post-install procedure?

Consider these two earlier bugs:

https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/477104?comments=all

https://bugs.launchpad.net/ubuntu/+source/lupin/+bug/477169?comments=all

Why update grub at all in Wubi?

Admittedly I'm not a Wubi fan because I live in a rural area where power outages are common and raise havoc with the Wubi FS, but I honestly wonder if Wubi installs shouldn't default to only security updates?

Is that even possible?

I just installed Ubuntu 10.04 on a clean partition (no Windows installed) and I am getting the same "no such disk" error followed by a blank screen. I installed the i386 version on a Pentium II machine. It boots ok from live CD.

@Doug, this is a different problem (this bug is specifically for wubi). Try creating a thread on ubuntuforums.org.

@Erick, I'm half inclined to agree about locking grub... but I think that's the whole point of the lupin overrides: so that grub acts differently on wubi installs. That's why I referred to that other bug in lupin that doesn't identify wubi installs on a partition other than the main windows partition. So I think they'll get to the point where grub updates are innocuous.

I was wondering at this point if this should "affect" Wubi or grub-pc? Or both?

After a bit of fiddling around I couldn't really figure out how to show that it affected both so I took the low road and subscribed Colin Watson. I swore not to do that frequently so I hope that's acceptable.

I truly believe if Colin has a look at this we'll see a solution in a timely manner.

I do have a plan for trying again to install Wubi on that old VIA machine but it could be several days before I have time.

There's something else interesting happening. I've seen 3 separate posts on wubi users that only have Windows in their grub menu after a fresh installation. They were quite consistent that they went from the windows boot manager to the grub menu, and only windows + recovery partition were present. Unfortunately I couldn't get a bootinfoscript to see what was up. e.g. http://ubuntuforums.org/showthread.php?t=1547207

Then I saw a post from user who had done a regular installation (no wubi), with a similar problem. This time there was a bootinfoscript and it shows grub installed to the windows partition (the bootloader looks to the windows partition, and core.img and grub.cfg are in the windows partition). They also had only windows in the grub menu when booting. Interestingly there was a wubildr and wubildr.cfg on the windows partition, but the user was quite categorical that they did not use wubi. I suspect that the user made an error when reinstalling grub2, but it's quite a strange result. http://ubuntuforums.org/showthread.php?t=1549204

I don't know if they're related, but thought I'd put it out here anyway. Since this thread is wubi+grub related.

Bug #609815 may be a duplicate of this one.

@bcbc,

I hadn't thought about this earlier, but I just did some 10.04.1 iso-testing today, and I see that includes Wubi testing:

http://iso.qa.ubuntu.com/qatracker/

If you had time to duplicate this error with the lucid/daily-live/20100816.1 image it might help greatly toward getting this bug fixed.

I'd help more but I've never been able to complete a Wubi install of 10.04 :^(

I finally got a Wubi install working! (Different hardware + fresh WinXP)

This is 10.04.1 and all went well. Since there were no updates to trigger a grub-update I ran the command "dpkg-reconfigure grub-pc" and after accepting the command line defaults I was presented with the typical debconf screen which showed only /dev/sda and it was NOT selected.

But then after accepting that I got a screen asking if I wanted to continue without installing grub. The default was NO!

Could a fix for this be as simple as changing the default to YES?

@Erick, it might...
But note, even if you did select /dev/sda (which is what the affected users did) it would have absolutely no impact - provided you installed wubi on the same partition as windows (as per my Follow Up comments in the bug description).

You can check this by:
1. looking for /host/wubildr (if it exists go ahead with the test with confidence that nothing should happen)
2. repeat the dpkg-reconfigure and select /dev/sda and press Forward
3. After completion, run bootinfoscript and check your MBR
There is no risk because you can backup and replace the MBR if need be (and bootinfoscript will show you what's in there) before rebooting - or just use lilo (that's what I did). But I think you'll find that it had no affect. That's what the lupin override does to grub on wubi.

It's the same as running grub-install /dev/sda - no affect on wubi (when it's installed on same partition as windows).
However, if you ran grub-install.real /dev/sda that would pooch the MBR.

I think the main thing is this: a typical wubi user has no knowledge of Ubuntu or linux. They probably don't know what an MBR or a bootloader. And when it says select where to install grub-pc: /dev/sda - it is frankly meaningless to them. After all, no one asked them to make this decision when they installed Wubi! So why do it now? My opinion is that grub-pc should be smarter - there's evidence everywhere that it's wubi (/ mounted on root.disk for instance), so why present anything at all?

PS I took your advice and did some lucid iso testing.

@ bcbc:

We once again have iso-testing beginning:

http://iso.qa.ubuntu.com/qatracker/

I clearly don't understand Wubi well enough to be of any real help but I can assure you that if this bug still exists in a 10.10 Wubi upgrade, and if you report this as an iso-testing bug, it will get some attention.

Feel free to PM me if you'd like. I'd really like to see this resolved.

@ Erick:
Done. The problem still exists and is likely to trick some new users who are forced to make a decision in the middle of the upgrade.

Maverick upgrade grub-pc popup:
============================
Title: Debconf on ubuntu
Banner: Configuring grub-pc
Checkbox: Continue without installing GRUB? (unchecked)
Button: Help, Forward

I clicked on Help:
You chose not to install GRUB to any devices. If you continue the boot loader may not be properly configured and when your computer next starts up it will use whatever was previously in the boot sector. If there is an earlier version of GRUB 2 in the boot sector, it may be unable to load modules or handle the current configuration file.
If you are already running a different boot loader and want to carry on doing so, or if this is a special environment where you do not need a boot loader, then you should continue anyway. Otherwise you should install GRUB somewhere.
Button: Close

I clicked Forward

it presented three options
/dev/sda (78518MB, ST98823AS)
/dev/sdb (100256 MB, OneTouch_II)
/dev/loop0 (1472MB, ???

I selected /dev/sda and clicked Forward. Grub installed to MBR pointing to partition #256

I just ran updates on Maverick and again, presented with a huge message - no grub device was found, blah blah may not be able to boot, then the next screen presented my hard drive and (loop0), the next screen the "You have not installed grub warning" with it defaulted to <No> so it will go back to the prior screen.

On top of that, lately whenever I run update-grub the following new error is shown:
/usr/sbin/grub-probe: error: /host/ubuntu/disks/root.disk is not a block device.

Setting up grub-pc (1.98+20100804-4ubuntu5) ...
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.35-20-generic
Found initrd image: /boot/initrd.img-2.6.35-20-generic
Found linux image: /boot/vmlinuz-2.6.35-19-generic
Found initrd image: /boot/initrd.img-2.6.35-19-generic
/usr/sbin/grub-probe: error: /host/ubuntu/disks/root.disk is not a block device.

I think this is just going to add confusion to wubi users. It shouldn't be too hard to identify that it's wubi and just bypass this all, in my opinion.

Solution if you are desperate to get Windows working again and don't care so much about Ubuntu:

I also suffered from this bug. I run Wubi and windows7 on my Asus UL30V laptop:
- upgrade Ubuntu yesterday to latest (don't remember version :-)
- at boot I get # No such device <strange serie of letters> and grub rescue

I then downloaded the wubildr and changed it for C: (and other locations where I found it!)
- Same fault.

I then started with a linux live-CD and downloaded ms-sys (used to fix windows MBR) as described in this link:
http://www.arsgeek.com/2008/01/15/how-to-fix-your-windows-mbr-with-an-ubuntu-livecd/

Now Windows7 starts directly an Grub is lost.

Any proposal how to get Grub back and use Ubuntu? Maybe I should skip Wubi and make a normal Ubuntu install?
/Svante

@Svante,
You shouldn't have replaced wubildr - that wasn't the issue and doing so likely caused your new problem. I don't know where you got it from and therefore no way of knowing whether that's the reason it won't boot.

When you say "grub is lost" I have no idea what that means. It really helps to just state what happens.

The whole wubildr thing is a bit of an undocumented mystery. A recent change (last year or so) saw the ability of grub to recreate the wubildr (through a lupin override) but this only works on Wubi installs to the same partition as windows. As mentioned in this bug report, this change also prevents the problems you had. I've seen nothing to indicate there are any immediate plans to address this.

The solution to your problems depends largely on whether you have anything important on the wubi install. If not, just reinstall or do a direct install to partition. Otherwise, either pull off your important data (loop mount the root.disk). Finally, if you've got some fully customized install you don't want to lose, it's possible to reinstall wubi, and then just replace the new root.disk with your one. (Make sure you copy it out of the \ubuntu folder before uninstalling). That usually will boot the old install fine.

The fact that you folks are getting a confusing dialog on upgrading grub-pc is bug 581760. I've uploaded a fix for that to maverick, which is awaiting release team review.

I don't think that this could have caused unbootability, though. Significant confusion, yes - but the grub-install diversion in lupin-support should have meant that things work pretty much no matter what you select in that dialog. Bug 604417 seems a more likely candidate for causing trouble here.

@Colin, that makes sense. When this bug was first created it wasn't clear that it only affected users who installed to a partition other than their main windows one. This has since been confirmed (or at least no exception to this has been identified).

This bug probably was also helpful in that it described what people were seeing - even if it's a combination of the 581760 and 604417 they probably wouldn't help a user recognize that that's what had happened to them. After all, I believe the lupin grub wrapper is mostly a hidden override and many users didn't even make a connection between installing grub-pc to /dev/sdx and the resulting error.

As I said above, I think the grub-pc prompt could be completely bypassed for wubi users as it serves no purpose.

I had this problem with a Windows XP machine not booting after the update . Here's how I fixed it:

Made a bootable USB stick using the HP tool (I think)
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&swItem=MTX-UNITY-I23839&jumpid=reg_R1002_USEN

1. Booted from an Ubuntu live cd
2. Used Ubuntu to find where c:\boot.ini was and copied that to the flash drive
3. Booted using the USB stick. This gave me the windows boot menu
4. Selected 'windows' and windows booted ok (if not you migth need to play around a litle with the boot.ini file)
5. Downloaded mbrfix from this site: http://www.ambience.sk/fdisk-master-boot-record-windows-linux-lilo-fixmbr.php
6. Used mbrfix as described on that page to fix the mbr on the hard disk. This will tell the hard disk to use the Windows boot menu rather than the
7. Rebooted the machine and it worked fine. The original windows boot menu was there so I could still choose between Windows and Ubuntu.

The following has been added to the Ubuntu Maverick release notes:
* Upgrading Wubi systems from 10.04 LTS is known to fail, and is not recommended at this time. (Bug:610898)

For the record, Comment #22 is *completely* incorrect. See comment #30 in bug 653134.

Had this same problem upgrading from 10.04 to 10.10 , while wubi was installed in D partition and Windows 7 on C.

Symptoms:
Not being to able to boot Ubuntu , while being to boot Windows7 successfully.

Solution:
Copying wubildr, wubildr.cfg, wubildr.mbr from C to D solved the problem smoothly.

Encounter this problem upgrading from 10.04 to 10.10. Window and Wubi on the same hard drive but different partition.

After restarted, system changed to grub rescue promote, and error message "unknown file"

@Lucas, reinstall the windows bootloader to fix.

Attached is a patch to the lupin-support package which should prevent grub-install.real from being used on wubi systems where wubi was installed to a disk other than "C:" . Instead on upgrades users with such a configuration will be warned that grub failed to install.

This is not a complete fix, and users with such a config will still eventually run into problems booting *Ubuntu* due to the core.img and modules never being updated to match incompatible updates to their grub.cfg . But their mbr won't be overwritten with a broken grub install, so they won't be prevented from booting Windows.

I have ideas for a complete fix but due to the seriousness of this bug (I'm seeing on average 1 person per day with an unbootable machine due to this bug in #ubuntu and #grub on irc.freenode.net alone) I think a simple patch that can more easily get an SRU and fixes the most critical aspect is important first.

I forgot an else statement in the previous patch. An updated patch is attached.

Jordan,
It's great you have a patch, but Wubi has an even bigger problem right now. The same grub update that is causing a spike in the overwritten bootloader problem (bug 581760) is also breaking Wubi installs that are on the same partition as windows (c:)
I am seeing a large number of these on ubuntuforums.org and answers.launchpad.net/wubi.
Although this fortunately still allows users to boot Windows, I do not know of a fix to the problem other than the workaround to loop mount and edit grub.cfg by hand.
It appears that this patch was not tested before releasing it, because a fresh install of Ubuntu 10.04.1 on 'drive C:' with the update applied does not boot.

This problem is almost identical in nature to the symptoms of bug 653134 (it appears to me that it's due to the same code patch but it was released on Maverick first) to which their has been no futher investigation by developers since the release of Maverick. If it is the same code patch that was known to break wubi installs on upgrade to Maverick, it is highly irresponsible that this was then released on 10.04.1 without addressing the problem.

All in all, I am dismayed by the poor development support Wubi receives and question whether Canonical should be making it available when these grub updates break it so easily.

The permanent fix to the grub problem for 10.04.1 installs on the same partition as windows is described here: http://ubuntuforums.org/showpost.php?p=10180622&postcount=13

It's the same for 10.10 wubi installs to the same partition described in bug 653134.

This is a manual workaround that allows the system to automatically update grub.cfg as required, but without continually breaking. The real solution requires a change to grub-pc install hooks that are beyond the scope of my capabilities.

Karl Bauers, when where and how was a fix for this bug released?

Setting back to triaged as this appears to have been accidentally set to Fix Released.

This thread is about the issue in wubi due to grub-pc updates, but I think I should mention here another case where it happened, WITHOUT ANY UPDATES at all.

This post is intended for guys who develop and maintain wubi or grub2, so I would go into detail to provide you most information.

Couple of days back I mentioned @ https://bugs.launchpad.net/grub/+bug/477104/comments/185 (which is on same issue in karmic) that by copying wubildr and wubildr.mbr from X:\ubuntu\winboot\wubildr onto X:\ solved the issue. After this change I updated ubuntu (I was on maverick), and could boot fine.

But I was wrong. Yesterday I couldn't boot again, and got the same old "Alert! /host/ubuntu/root.disk not found. Dropping to shell!" followed by (intrafms) prompt. Here I tried a few recovery steps mentioned in Wubi megathread (http://ubuntuforums.org/showthread.php?t=1639198). After trying to manually boot, I got an "ata10: SATA link down" error. I thought something was wrong with my partition, so I rebooted to windows, and uninstalled wubi. I deleted the partition and formatted afresh. I have two drives - sda is where I have windows, sdb is where I install ubuntu (both in 1st partitions). The exact partitions are verified by boot-info-script.

I did a 20GB clean maverick wubi install on the 22GB sdb1. I logged in to ubuntu desktop fine, and unlike other occasions, did not update anything. I shut down ubuntu. I booted again, and found myself at intrafms prompt!

So it is not because of only grub-pc "update". It seems to be the "combination" of grub2 and wubi that causes the problem.

In the intrafms prompt, the contents of /host were found to be same as that of sda1, i.e. C drive. To make the bootloader find ubuntu root disk in it, it must point to /dev/sdb1, because there is no root.disk in C:. Now I mounted /dev/sdb1 to /mnt/win1. When I checked its contents, it was same as /dev/sda1, and NOT sdb1.

Hence it makes sense why this issue is for a diff wubi partition than C:. If wubi was installed in C:, /host would have always found root.disk.

When I see my devices, I see all partitions of sda and sdb, so effectively all the partitions that matter in this business are shown in /dev. The fact is the drives are not mounted properly.

In the last 4 days, I have tested all ubuntu >= 9.10 as they ship with grub2. I found the issue in all of them. What is of most concern is the recent finding that even without any update, ubuntu maverick failed to boot. Therefore I think it's just a matter of luck if by following one of the several solutions in forums, you are able to boot. The problem is elsewhere.

We can argue about why wubi should be used in the first place if we are serious about ubuntu. But since we officially include wubi, we must address this problem. If wubi is not compatible with grub2, then why not ship it with grub-legacy? Or maybe a wubi-specific ISO having grub legacy? No matter how important security updates need to be installed, a bootloader should be undisturbed. And in the first place, a "compatible" version of the most important program in an OS should be used.

@Arolk, re. your email, you need to reinstall the windows bootloader. See Problem #1, Solution #1 or #2 in http://ubuntuforums.org/showthread.php?t=1639198 (not Problem #2)
If you have any issues you can post on that thread for help. Hope that helps.

(Adding to comment #33 above)

Another (worse) form of the issue:

Although it uses the same bootloader+wubi combo as the affected ones, I casually tried Kubuntu Maverick today. The issue could be reproducible even quicker. This time I got "Alert! /host/ubuntu/root.disk not found. Dropping to shell!" just after the machine rebooted for the second time during installation (just to recall the two instances of reboot during installation - 1st is when you complete wubi wizard in windows, 2nd is when it finishes installation before loading the desktop).

Yes, not simply chkdsk, I did full format of the partition before install, if you are asking (I don't think it matters).

Well, so the issue does occur
1. after updates
2. without updates
3. even before it is fully installed!

on 9.10/ 10.04/ 10.10

Practically, at EVERY instance of grub2+wubi usage.

If there is anyone from Canonical Release team reading this, please make it a point to release a grub-legacy + wubi ISO of the latest Ubuntu at least, till the issue is resolved. This is not less than a show stopper.

Btw, one small correction in comment #33: i meant initramfs, not intrafms.

@Mayukh,
It sounds like you have a different problem, perhaps specific to your computer. This bug is specifically related to grub updates that result in the grub bootloader being installed over the windows bootloader. I'm guilty too of bringing up a recent grub issue but only because I mentioned this symptom in the bug description "side note": that a Wubi installed on the same partition doesn't boot - but it never evens gets to the grub menu. Whereas in your case, you must be getting to the grub menu. I would guess that your bios is flipping your drive devices. Or something else, but if it was a widespread issue with Wubi since grub2 was introduced in 9.10, I think that would have been evident by now.

@bcbc

Yes I am able to get to the grub menu, but after that, mount does not happen correctly. Thats why if I check the contents of /host, I get that of C:\, and not the drive where I installed wubi. There is nothing wrong with the grub script (I get correct drive for root).

I am perhaps wrong in generalizing the issue in earlier comment, because I do not get the issue on using clean 9.10 install (WITHOUT updates of kernel and grub). But I can confirm the issue in 10.04 and 10.10, and also in 9.10 by updating to a later kernel than 2.6.31-14 and a later grub2 than 1.97~beta4-1ubuntu3 (the base versions that come with 9.10). I think the issue would be with the later versions of them combined with wubi.

If my BIOS was flipping my devices, then I would have got same issues with 9.10 base install.

I will find the correct bug corresponding to my problem (because I can get to the grub menu unlike being unable to boot any OS at all) and add my comments. But with my experience of using wubi >9.04, it wouldn't be correct to give a green flag to grub2/ wubi and suspect my bios.

Update - users affected by this bug and have fixed it by patching their MBR may then go on to be affected by bug 682337 (choosing Ubuntu either results in reboot, hang, or grub prompt).

The fix is describe in the Wubi megathread (http://ubuntuforums.org/showthread.php?t=1639198) Problem #2, Solution #1. Once you have it booting, you need to apply the Permanent Fix documented there.

If you have been affected by the MBR being overwritten you can proactively apply the permanent fix to avoid future problems.

I've been doing some paperwork today - linking Questions from answers.launchpad.net to the relevant bug. For those people that are receiving emails today many of whom solved the problems a month ago - please ignore - bugs are treated as higher priority when more people are affected so this is an attempt to get the problem fixed.

I've been looking at how wubildr.mbr works - it finds and uses the first wubildr by scanning the root of all partitions, in BIOS order. On my computer the C: drive is the second partition and it never uses C:\WUBILDR. It always uses the one on my recovery partition /dev/sda1.

So Grub2 is using the existence of /host/wubildr to tell if it's a Wubi install, but I can delete it and it still boots fine - it's an 'artifact' as cjwatson would say. Therefore it shouldn't harm anything to have another 'artifact' on the /host partition when Wubi isn't installed on the Windows partition. If Grub2 considers this a Wubi indicator, there should either always be a /host/wubildr (or it shouldn't consider it important at all - i.e. the fact that root is loopmounted on /host/ubuntu/disks/root.disk should be enough).

Note that when Grub2 does find /host/wubildr - it updates it - to be compatible with the latest grub changes. The problem is, the one it updates often isn't the one used to boot. It really should be doing what WUBILDR.MBR does - check each partition in order and update the first one it finds (and/or update all it finds). This might also explain the booting problems we've been seeing lately when Wubi is installed to the same partition as Windows (bug 682337)

   Hello:

 Sorry to disturb you again.

 It is the third time when I can not boot in Ubuntu.

  Every time I Install any system updated it happens the same way.

  After the second time happened, I did lock the Grub, so I will never have
the same problem.

  Few days ago I installed some updates (I looked through them, but I did
not notice anything related to grub, just some related to some library ?? )

@ Alex,

Check out the Wubi megathread that bcbc linked to in post #38. There is a more "permanent" work-around there.

  Thanks,

 I fixed it again.

 One month ago I did lock the grub in the System; I do not know what kind of
update I installed, so it rendered my Ubuntu unbootable ??

  Cheers,

  Alex

On Sat, Feb 5, 2011 at 8:50 PM, Erick Brunzell <email address hidden> wrote:

> @ Alex,
>
> Check out the Wubi megathread that bcbc linked to in post #38. There is
> a more "permanent" work-around there.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/610898
>
> Title:
> grub-pc upgrade renders computer unbootable when Wubi is installed to
> partition other than Windows
>
> Status in Release Notes for Ubuntu:
> Invalid
> Status in Wubi, Windows Ubuntu Installer:
> Triaged
> Status in “lupin” package in Ubuntu:
> Triaged
> Status in “lupin” source package in Natty:
> Triaged
>
> Bug description:
> Users with wubi 10.04 are running the latest grub-pc updates, and it's
> installing the grub2 bootloader to their drive MBR, rendering their
> computers unbootable.
>
> Users are reporting that the computer boots straight to a grub rescue
> prompt, with the error 'no such device xxxxxxx'. They cannot boot
> windows or access their system restore utilities. Grub2 is in the MBR
> pointing to partition #256.
>
> I first reported this on the #grub IRC channel, in the following bug
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/576724, and now
> here as it's probably correct to create a new bug (an there's been no
> response yet).
>
> Here are the links to the ubuntuforums.org threads...
> http://ubuntuforums.org/showthread.php?t=1538228
> http://ubuntuforums.org/showthread.php?t=1537956
> http://ubuntuforums.org/showthread.php?t=1538170
> http://ubuntuforums.org/showthread.php?t=1482621 (this is an older
> thread, but a new user (softis) added to it and has the same issue).
> http://ubuntuforums.org/showthread.php?t=1540744
> http://ubuntuforums.org/showthread.php?t=1540772
> http://ubuntuforums.org/showthread.php?t=1539672
>
> I suspect, but cannot be certain, that it may be related to another
> bug in the lupin-support overrides of grub, that fails to identify a
> wubi installed ubuntu, when it has been installed to a partition other
> than the main windows partition.
> https://bugs.launchpad.net/ubuntu/+source/lupin/+bug/604417
>
> Although not conclusive, it seems that the most affected users
> reported installing wubi to a partition other than windows.
>
>
> =====================
> FOLLOW UP: Aug 13 2010
> =====================
> I ran a new 10.04 wubi install on two computers. On the first wubi was
> installed on the same partition as windows. On the second it was installed
> on an external drive.
>
> After installing, I booted wubi on both, connected to the internet and
> immediately downloaded all updates. When the grub-pc screen was presented, I
> clicked Forward (without checking the box) and then proceeded to select ALL
> devices presented to install grub.
> On the WUBI on the same partition as Windows, this had no effect (verified
> with Bootinfoscript)
> On the WUBI on a different partition than Windows, this installed grub to
> th...

This bug has dragged on far too long, and having cleared away some other Wubi bugs I'm finally ready to attack this one. Sorry for taking so long about it.

wubildr.mbr iterates over all partitions (or drives in Windows-speak) and chainloads the first /wubildr (i.e. must be in the root directory) it finds. As such, Wubi is making life difficult for itself by installing wubildr to C: (or, strictly, all drives containing boot.ini). It should really copy it just to the installation target drive; anything else is complexity for the sake of complexity.

So far so good. However, the hard bit is coping with old installations. The substitute grub-mkimage that lupin-support installs is a Unix program, and so works within the Unix filesystem hierarchy; how should it update wubildr on all these partitions that may not even be mounted? Going around and speculatively doing read-write mounts of all the filesystems we can find is generally a recipe for data loss if another operating system was hibernated on the same computer. I'm not certain how big an issue this is, since presumably /host itself would face a similar problem; Linux's NTFS driver has code which at least tries to detect hibernation signatures and refuse to perform a read-write mount, although its FAT driver does not. All the same, I want to minimise the risk from this.

My best candidate so far is to use grub-probe and grub-fstest. These can, respectively and among other things, check the filesystem in use on a partition, and test the existence of a file on a given filesystem, both in a provably read-only fashion. This suggests an algorithm such as the following pseudocode:

  for each partition:
    fs=$(grub-probe $partition)
    if fs in ("fat", "ntfs") and $(grub-fstest $partition ls /wubildr) != "":
      if fs == "fat" and $(grub-fstest $partition ls /hiberfil.sys) != "":
        tmp=$(mktemp)
        grub-fstest $partition cp /hiberfil.sys $tmp
        if size($tmp) < 4096 or first 4096 bytes of $tmp are all zeroes:
          fail("$partition contains Windows hibernation signature")
      tmpdir=$(mktemp -d)
      mount $partition $tmpdir
      update $tmpdir/wubildr
      umount $tmpdir

I've left out lots of details, of course, but I think this is a workable outline. In lucid and maverick, we'll need to enable building grub-fstest and ship it in grub-common, since it's currently missing there (natty has it, though); this would be convenient for GRUB upstream in any case when working with users to diagnose problems. '/usr/share/lupin-support/grub-mkimage --test' could be kept reasonably fast on non-Wubi systems by checking for /host/ubuntu/winboot/ before running lots of grub-probe and grub-fstest commands.

This is going to be a slow and complex operation, and it would be nice to avoid having to do this forever. We could have Wubi drop its build number into /host/ubuntu/winboot/, and then check that to see whether we need to look anywhere other than /host/wubildr.

A variant of this, perhaps simpler, would be to remove any wubildr binaries found by the above process that aren't on a filesystem containing /ubuntu/winboot/wubildr.cfg or similar, and generate /host/wubildr ...

One issue... if wubildr is only on the target partition then it will
grub4dos fail in some cases e.g. if you install to a partition that falls
after an ext4 partition (the version of grub4dos that wubi uses gets stuck
on these - probably a more recent version of grub4dos version would solve
this). This is not likely a problem for typical Wubi users but people that
test Wubi will run into this. You mentioned replacing grub4dos on another
bug - this would resolve that.

Regarding hibernation - if Windows is hibernated it's not possible to boot
Wubi (the windows boot manager boots straight into windows) so that
shouldn't be an issue except perhaps if there are multiple versions of
Windows (not sure how that would work).

ext4: Thanks. I'll see if I can add this to my tests. Is it only ext4,
or ext3 as well? And does anyone actually care about wubildr.mbr being
able to read data from an ext[234] filesystem? I suspect that the
easiest fix may be to disable ext[234] support in wubildr.mbr
altogether.

(While I do want to replace grub4dos with grub2 ntldr-img, this is too
invasive for a change to lucid/maverick, so I'll need to figure out a
small patch to grub4dos for this anyway.)

Hibernation: That's useful information, thanks; I wasn't aware of that
behaviour of the boot manager.

An issue that comes to mind is that we have no way to upgrade wubildr.mbr. Thus, if there are known situations where moving wubildr to a different disk will break it, I have no choice: my alternative solution isn't safe, and we have to stick with updating wubildr on whatever partition currently contains it.

This bug was fixed in the package lupin - 0.34

---------------
lupin (0.34) natty; urgency=low

  * Use 'set -e' rather than '#! /bin/sh -e', to avoid accidents when
    debugging with 'sh -x'.
  * Fix output of '/usr/share/lupin-support/grub-probe --target=partmap' to
    be 'msdos' rather than 'part_msdos'.
  * Detect the case where Wubi's disk images were installed to a different
    partition from Windows, which means that wubildr will not be on /host:
    update all wubildr images we can find (LP: #610898).
  * Add the vbe, vga, video_bochs, and video_cirrus modules to the wubildr
    image.
 -- Colin Watson <email address hidden> Wed, 06 Apr 2011 16:23:13 +0100

The Lucid and Maverick versions of this change are blocked on getting the update for bug 687501 validated and released, so that will take at least a week or two from now.

Only ext4 as far as I know - it hangs when it tries to read them (hard
reboot required). This only affects users whose Ubuntu partition is prior to
window e.g. /dev/sda1 = ext4. Most Windows users have windows on /dev/sda1
or /dev/sda2. But this is not always the case. And if you install Wubi to an
external or logical drive it increases the likelihood that an ext4 could be
encountered.

I think a version of grub4dos that is later than the one wubi users (2007?)
should be able to read ext4 fine.

On Wed, Apr 6, 2011 at 1:13 AM, Colin Watson <email address hidden> wrote:

> ext4: Thanks. I'll see if I can add this to my tests. Is it only ext4,
> or ext3 as well? And does anyone actually care about wubildr.mbr being
> able to read data from an ext[234] filesystem? I suspect that the
> easiest fix may be to disable ext[234] support in wubildr.mbr
> altogether.
>
> (While I do want to replace grub4dos with grub2 ntldr-img, this is too
> invasive for a change to lucid/maverick, so I'll need to figure out a
> small patch to grub4dos for this anyway.)
>
>

I updated my current non-windows Natty install and it updated lupin-support to the latest version. So I reran dpkg-reconfigure grub-pc. It ran grub-install and it updated my wubildr on the Windows partition /dev/sda2 correctly (install is on /dev/sda3). The only downside is that it prompted me where to install Grub and gave me two choices: /dev/sda (checkbox not selected) and /dev/loop0 (checkbox selected). I left /dev/loop0 selected and proceeded. Reboot worked successfully.

This may not be a great test case as that Natty was a bit beaten. I'm going to run a maverick to natty upgrade test on the non-windows partition soon and I'll report back on what I find. I'll confirm whether the /dev/sda prompt is given on upgrade.

But in terms of the wubildr update on the different partition - it worked perfectly!.

Did a fresh maverick install and then upgrade to Natty on a non-Windows partition. No prompt on where to install grub, and it updated wubildr correctly. After booting into Natty I could run "grub-install" and it correctly updated wubildr on the windows partition without any prompts and did not allow install to the drive MBR.

The following showed my tests :
bcbc@ubuntu:~$ mount | grep '/host'
/dev/sda3 on /host type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
bcbc@ubuntu:~$ sudo grub-install /dev/sda2
Installation finished. No error reported.
bcbc@ubuntu:~$ mount | grep /dev/sda2
bcbc@ubuntu:~$ sudo mount /dev/sda2 /mnt
bcbc@ubuntu:~$ ls -l /mnt/wubildr
-rwxrwxrwx 1 root root 148091 2011-04-06 22:43 /mnt/wubildr
bcbc@ubuntu:~$ date
Wed Apr 6 22:43:33 PDT 2011
bcbc@ubuntu:~$ sudo grub-install /dev/sda
Installation finished. No error reported.
bcbc@ubuntu:~$ ls -l /mnt/wubildr
-rwxrwxrwx 1 root root 148092 2011-04-06 22:44 /mnt/wubildr

bcbc@ubuntu:~$ sudo debconf-show grub-pc
[sudo] password for bcbc:
  grub-pc/kopt_extracted: false
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub-pc/install_devices: /dev/loop0
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
* grub2/linux_cmdline:
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_disks_changed:
* grub2/linux_cmdline_default: quiet splash
  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: true
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/timeout: 10

Thanks for testing. I'm glad to hear confirmation that this saga may
finally be nearing its end.

For the record, I wouldn't recommend propagating the idea that 'sudo
grub-install /dev/sda2' is a good thing to run on Wubi. The correct
command is:

  sudo grub-install /dev/loop0

As it happens, it makes no difference right now, because lupin-support
overrides everything with a large hammer so that it makes absolutely no
difference what device you tell grub-install to use - /dev/loop0,
/dev/sda2, /dev/sda, etc. will all behave the same way. In the future,
though, we may change this, so please don't assume that anything other
than /dev/loop0 will work.

I don't think anyone is doing the grub-install on Wubi intentionally -
sometimes they will follow bad instructions and do it. So the sledgehammer
approach is good (that's what I was testing). I wasn't aware of
"grub-install /dev/loop0" being useful - thought it was more a glitch that
grub had that in the list, so I'll note that (although I suspect it will be
unnecessary to ever do this if everything is working as it should).

In terms of there being another grub update on Maverick prior to providing
this fix - that will likely cause problems. If at all possible they should
be combined as any grub update will break a Wubi install (so far Maverick
has remained safe excluding the upgrade from Lucid).

Anyway - I'm happy to see the fix come out. Thanks for the effort.

On Thu, Apr 7, 2011 at 4:26 AM, Colin Watson <email address hidden> wrote:

> Thanks for testing. I'm glad to hear confirmation that this saga may
> finally be nearing its end.
>
> For the record, I wouldn't recommend propagating the idea that 'sudo
> grub-install /dev/sda2' is a good thing to run on Wubi. The correct
> command is:
>
> sudo grub-install /dev/loop0
>
> As it happens, it makes no difference right now, because lupin-support
> overrides everything with a large hammer so that it makes absolutely no
> difference what device you tell grub-install to use - /dev/loop0,
> /dev/sda2, /dev/sda, etc. will all behave the same way. In the future,
> though, we may change this, so please don't assume that anything other
> than /dev/loop0 will work.
>
> --
>

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!

Accepted grub2 into maverick-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!

Testcase 1: Maverick install on non-windows partition
========================================
Installed Wubi maverick 10.10 on my E: 'drive' (ntfs partition /dev/sda3).
Ran all standard updates.
Added Proposed to the sources.
Processed all proposed updates.

Expected result
===========
1. /wubildr on C: 'drive' (/dev/sda2) would be updated
2. No prompt to suggest installing grub2 bootloader to /dev/sda
3. New grub modules placed in /boot/grub
4. Different grub.cfg

Results
======
1. /wubildr on C: 'drive' was not updated. Remains at version
1.98+20100804-5ubuntu2
Grub2 version (grub-install -v) shows 1.98+20100804-5ubuntu3.3
debconf-show grub-pc shows grub-install devices are blank.
2. There was no prompt to suggest installing grub2 bootloader on /dev/sda2
3. No additional files in /boot/grub
4. No difference in grub.cfg (except the addition of the new kernel in
proposed)

Comments:
a. Positive that there is no prompt that user could select to install grub
bootloader to drive MBR
b. OK that wubildr isn't updated, because the grub.cfg also doesn't contain
the instructions that cause the loopback memory corruption.
c. But result not quite as expected (or is my understanding incorrect?)

Testcase 2: Maverick install on windows partition
====================================
Installed Wubi maverick 10.10 on my C: 'drive' (ntfs partition /dev/sda2).
Checked "debconf-show grub-pc" beforehand: grub-install devices was blank.
Ran most 10.10 standard updates (servers are very busy so couldn't get a
bunch of new ones).
Added Proposed to the sources.
Updated grub-pc and grub-common in Synaptic.

Expected result
===========
1. /wubildr on C: 'drive' (/dev/sda2) would be updated
2. New grub modules placed in /boot/grub
3. Different grub.cfg

Results
======
1. /wubildr on C: 'drive' was updated.
debconf-show grub-pc now shows grub-install devices: /dev/loop0
There was no prompt to suggest installing grub2 bootloader (as expected)
3. All grub modules added to /boot/grub
4. grub.cfg was different (matching normal install)

Comments:
This shows a big difference between Wubi installed on the Windows partition
(/host/wubildr exists) and wubi installed on the non-windows partition (no
/host/wubildr).

Testcase 3: Lucid 10.04.2 on E: drive (ntfs partition /dev/sda3)
=============================================
Grub version in wubildr at install 1.98-1ubuntu5
Grub version in Ubuntu at install 1.98-1ubuntu10
debconf-show grub-pc ---> install-devices: <blank>

Test method:
Add Proposed to sources, and update grub-pc through synaptic (not running
other updates)

Expected result:
===========
1. wubildr on /dev/sda2 will be updated (that's C:)
2. grub modules added to /boot/grub
3. /boot/grub/grub.cfg changes as expected with new modules present.
4. No prompt to install grub to /dev/sda

Results:
=====
1. wubildr on /dev/sda2 not updated
2. grub modules not added to /boot/grub
3. /boot/grub/grub.cfg not changed
4. There was no prompt to install grub to /dev/sda

(grub is now version 1.98-1ubuntu12)

Conclusion:
========
This will stop this bug (installing grub to drive MBR). But I expected
wubildr to be updated. Maybe my expectation is incorrect, but there is still
a distinct difference between wubi installed to the same partition as
windows (/host/wubildr exists), and when it doesn't.

Testcase 4: Lucid 10.04.2 on C: drive (ntfs partition /dev/sda2)
=============================================
Grub version in wubildr at install 1.98-1ubuntu5
Grub version in Ubuntu at install 1.98-1ubuntu10
debconf-show grub-pc --> install-devices: <blank>

Test method:
Add proposed to sources and update grub-pc through synaptic (not running
other updates)

Expected result:
===========
1. wubildr on /host (/dev/sda2) will be updated
2. grub modules added to /boot/grub
3. grub.cfg contains extra code (similar to normal install)

Results
======
1. wubildr on /host updated
2. grub modules added to /boot/grub
3. grub.cfg contains extra code

grub is now 1.98-1ubuntu12
debconf-show grub-pc --> install devices changed to /dev/loop0

Conclusion
========
Results as expected, but there is still a distinct difference between wubi
not installed to the same partition as windows.

PS Grub menu (from wubildr) now shows 1.98-1ubuntu12 (as expected)

NOTE:
I don't plan to do any more tests at this point, unless the code changes.
Although I expected the code to work more like Natty (updating wubildr no
matter which partition it is installed to), on the positive side, it doesn't
prompt to install grub to the MBR. And when it does update the grub.cfg to
the state that caused the memory corruption on recreating the loopback
device, it also updates the wubildr - to prevent the booting problem.
Although the same bad wubildr will exist on the non windows partition
installs, the bug shouldn't be triggered.

However, installs with a bad wubildr where it is still booting (I've seen
cases where the corruption only occurs following a subsequent kernel update)
might still have problems.

Also, it seems that the grub-install-devices is a factor in whether the
wubildr is updated on non-windows partition installs, but not on windows
partition installs.

I think what happened here is that I forgot to upload the lupin-support changes, which are vital to fixing this bug. I'll get those uploaded ASAP. Sorry for the oversight!

Accepted lupin 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!

Accepted lupin into maverick-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!

bcbc, if you would have some time to retest this, I would greatly appreciate it - your previous reports were thorough and helpful!

Repeat of Lucid testcase 3 (different partition than windows' main drive):

Testcase 3: Lucid 10.04.2 on E: drive (ntfs partition /dev/sda3)
=============================================
Grub version in wubildr at install 1.98-1ubuntu5
Grub version in Ubuntu at install 1.98-1ubuntu10
debconf-show grub-pc ---> install-devices:  <blank>

Test method:
Add Proposed to sources,through synaptic (not running other updates)
Latest version of grub-pc shown as 1.98-1ubuntu12
Latest version of lupin-support is 0.29.1
Select grub-pc (which includes) grub-common and lupin-support and
applied updates.

Expected result:
===========
1. wubildr on /dev/sda2 will be updated (that's C:)
2. grub modules added to /boot/grub
3. /boot/grub/grub.cfg changes as expected with new modules present.
4. No prompt to install grub to /dev/sda

Results:
=====
1. wubildr on /dev/sda2 updated to 1.98-1ubuntu12
2. grub modules added to /boot/grub as expected
3. /boot/grub/grub.cfg changed as expected
4. There was no prompt to install grub to /dev/sda
 (grub is now version 1.98-1ubuntu12)

Conclusion:
========
The test was successful.

PS I will try and run the maverick failed test case next. The "same
partition" tests will be run last, probably later this evening
(pacific time).

PS should have mentioned in Results of last testcase (repeat testcase 3)
1. After update, debconf-show grub-pc shows installed-devices: /dev/loop0
2. No wubildr on /host before or after test (expected)
3. Also, I rebooted into Ubuntu following the updates to confirm it worked (kind of
important to mention this)
--------------------------------------

Repeat of testcase 1 follows...

Testcase 1: Maverick 10.10 on E: drive (ntfs partition /dev/sda3)
=============================================
Grub version in wubildr at install 1.98+20100804-5ubuntu2
Grub version in Ubuntu at install 1.98+20100804-5ubuntu3
Lupin-support version is 0.32
debconf-show grub-pc ---> install-devices: <blank>
Only grub.cfg and grubenv in /boot/grub
No wubildr on /host

Test method:
Add Proposed to sources,through synaptic (not running other updates)
Latest available version of grub-pc shown as 1.98+20100804-5ubuntu3.3
Latest available version of lupin-support is 0.32.1
Select grub-pc (which includes grub-common) and lupin-support and
applied updates.

Expected result:
===========
1. wubildr on /dev/sda2 will be updated (that's on C:)
2. grub modules added to /boot/grub
3. /boot/grub/grub.cfg changed as expected with new modules present.
4. No prompt to install grub to /dev/sda

Results:
=====
1. wubildr on /dev/sda2 updated to 1.98+20100804-5ubuntu3.3 and no /host/wubildr (expected)
2. grub modules added to /boot/grub as expected
3. /boot/grub/grub.cfg changed as expected
4. There was no prompt to install grub to /dev/sda
 (grub is now version 1.98+20100804-5ubuntu3.3 on Ubuntu)
5. debconf-show grub-pc install-devices: /dev/loop0
6. Rebooting into Ubuntu worked

Conclusion:
========
The test was successful.

PS as mentioned before - the same partition tests will be done later this evening. They probably aren't as critical since they worked before the lupin update anyway. But I'll do them to make sure there's no regression.

Reran testcases 2 and 4 (Maverick and Lucid install on same partition as Windows). The test case involved adding -Proposed and just upgrading packages grub-pc, grub-common, and lupin-support. The results were the same as reported before.

Conclusion
=======
Grub updates with the latest lupin-support deliver identical results regardless of where wubi is installed.

I'll probably do one more test with Wubi installed on an external drive. But as far as I can see - this is working exactly as intended. Good job!

Wubi 10.04.2 on external drive worked the same. So I'm 5 for 5.

I'm wondering what happens to users who've locked grub-pc and grub-common, but who might allow the update to lupin-support to be processed. These are mostly 10.04 users, or those who upgraded to 10.10 and were burned with booting problems.

Will the postinst script for lupin-support do a grub-install?

Re. my last comment, I just tested it and it appears that the Update Manager won't allow you to select the new lupin-support when an older version of grub-pc is locked. Trying to do it manually in synaptic causes synaptic to want to uninstall grub-pc. So there is a hard dependency on the latest version of grub-pc.

That's good.

Hooray. Marking verification-done, then. Thanks for the extensive tests!

lupin-support.postinst doesn't do a grub-install, but I think that's OK - once the new lupin-support is unpacked, grub-pc.postinst will take care of that.

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

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

  * Fix use of freed memory when replacing existing loopback device
    (LP: #742967).
  * Make sure to reinstall GRUB on upgrade if Wubi is in use (LP: #742967).
  * Enable grub-fstest, so that we can use it to help find wubildr
    (LP: #610898).
  * Make NTFS UUIDs uppercase (LP: #695290).

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

  * Backport multipath probing fixes (LP: #687501).
 -- Colin Watson <email address hidden> Wed, 27 Apr 2011 10:39:15 +0100

This bug was fixed in the package lupin - 0.29.1

---------------
lupin (0.29.1) lucid-proposed; urgency=low

  * Detect the case where Wubi's disk images were installed to a different
    partition from Windows, which means that wubildr will not be on /host:
    update all wubildr images we can find (LP: #610898).
 -- Colin Watson <email address hidden> Mon, 06 Jun 2011 16:10:13 +0100

This bug was fixed in the package grub2 - 1.98+20100804-5ubuntu3.3

---------------
grub2 (1.98+20100804-5ubuntu3.3) maverick-proposed; urgency=low

  * Fix use of freed memory when replacing existing loopback device
    (LP: #742967).
  * Make sure to reinstall GRUB on upgrade if Wubi is in use (LP: #742967).
  * Enable grub-fstest, so that we can use it to help find wubildr
    (LP: #610898).
  * Make NTFS UUIDs uppercase (LP: #695290).

grub2 (1.98+20100804-5ubuntu3.2) maverick-proposed; urgency=low

  * Backport multipath probing fixes (LP: #687501).
 -- Colin Watson <email address hidden> Wed, 27 Apr 2011 10:32:26 +0100

This bug was fixed in the package lupin - 0.32.1

---------------
lupin (0.32.1) maverick-proposed; urgency=low

  * Detect the case where Wubi's disk images were installed to a different
    partition from Windows, which means that wubildr will not be on /host:
    update all wubildr images we can find (LP: #610898).
 -- Colin Watson <email address hidden> Mon, 06 Jun 2011 16:11:29 +0100

While I'm here, @bcbc: I did some work on the ext4 problem you mentioned. In fact, when I tried to set up a test case, I found that wubildr.mbr hung for me on an ext3 filesystem, never mind ext4. This turned out to be due to lack of support for inode sizes other than 128, and I've backported a patch for this to ntldr-img which should be used in future Wubi builds:

grub2 (1.99-8) unstable; urgency=low

  [ Robert Millan ]
  * Avoid buggy versions of libgeom-dev (see #630107). Closes: #630197
  * Fix grub-probe detection for ATA devices using `ata' driver on kFreeBSD 9.
    - kfreebsd-9_ada_devices.patch

  [ Colin Watson ]
  * Update ntldr-img from grub-extras:
    - Handle ext3 inode sizes other than 128.

  [ Debconf translations ]
  * Kazakh (Baurzhan Muftakhidinov). Closes: #630915

 -- Colin Watson <email address hidden> Tue, 21 Jun 2011 02:10:10 +0100

Once I'd fixed this, wubildr.mbr had no problem with my test ext4 filesystem. I therefore suspect that perhaps your ext3 filesystem predated the change of the default inode size to 256?

It would be worth testing Oneiric Alpha 2 when it's released (using a fresh install, since upgrades don't replace wubildr.mbr) to find out whether it fixes this problem for you too. If it doesn't, I'd appreciate a separate bug report.

@Colin,

This was a problem I had noticed cropping up every now and then on the
forums. I made the assumption that it was ext4 and not the inode size. I had
confirmed it on ext4 but haven't done extensive testing to figure out the
exact problem.

Anyway - I just did a test with the wubildr.mbr from the latest Oneiric
wubi.exe and removed wubildr - now it goes past my ext4 partition and
reports "cannot find grldr on all devices. Press CTRL-ALT-DELETE to
restart". So it looks like your fix is working great.

I'll do more tests when alpha 2 comes out as well.