Fresh Wubi 10.04 install + grub update renders system unbootable

[Alex van der Wal]

Steps to reproduce:
Install 10.04 (32-bit desktop edition) within Windows using Wubi.
Boot Ubuntu and start a package update. This updates 'grub'.
During the package install phase, 'grub' pops up a window that asks you whether or not to perform the update.
If you do NOT choose to abort, but choose to let 'grub' update the system, it overwrites the windows master boot record.

Result:
This bricks the system since neither Windows or Linux boot (since both depend on the Windows bootloader).
The solution is to use a recovery disk/stick to replace the MBR by a windows version again. This is not for everyone.

So there are 2 problems here:
- A newbie user can brick his system. Great way to popularize Linux.
- 'grub' manages to ask difficult questions (to inexperienced users) during a routine package update.

P.S. Sorry for the ad-hoc bug report. This needs analysis by someone who knows what he/she is talking about. Is this a grub, wubi or generic Ubuntu issue? The problem is real though.

[Jordan (jordanu)]

Could you please check if the package "lupin-support" is installed? Running "apt-cache policy lupin-support" in a terminal will tell you.

[nUboon2Age (nuboon2age)]

On 8/14/10 in #ubuntu a number of us supported xissburg for something like 15 hours as this bug was preventing booting. Finally xissburg solved it by using a Windows7 recovery CD, but we left it before xissburg had been able to reestablish the 2nd entry in the bootloader for Win XP or their wubi ubuntu install.

Windows 7 Ultimate x64, home built,PC. Intel Pentium Dual Core E2200, 4GB RAM DDR2 667 MHz, HDD 320 GB, Mobo P5N-E SLI
Wubi install ubuntu 10.04 32bit

Noted: xissburg also had some version of XT as the second entry in the windows boot loader and had split the hard disk equally between Win 7 and XP.

At one point in the troubleshooting this was xissburg'sd partition info: http://imagebin.org/109698 .

Xissburg left contact info w/ me so if more info is needed it is possible i may be able to contact xissburg and obtain it.

[nUboon2Age (nuboon2age)]

This may be a duplicate of Bug #610898.

[bcbc (bcbc)]

I think this is also a duplicate of https://bugs.launchpad.net/ubuntu/+source/lupin/+bug/604417 which is a problem in the lupin overrides of grub, as it relies on the existence of the file /host/wubildr to determine if it's a wubi install.
If you don't install wubi on the same partition as windows, then /host/wubildr does not exist, so it assumes it's a real ubuntu install and uses the real grub commands, not the lupin override.

[nUboon2Age (nuboon2age)]

bcbc: This bug may relate to #604417, but in the instance i observed with xissburg wubi was installed on the same partition as Win 7. In xissburg's system there was an original XP partition, then a second Win 7 partition. Wubi was installed on the Win 7 partition. Then a Wubi Ubuntu install was added and it appeared that the windows bootloader (i would think that was a Win 7 boot loader since Win 7 was added later and was the first entry in the boot loader, but can't say with 100% certainty) was disrupted after a grub update to Ubuntu.

[nUboon2Age (nuboon2age)]

The log of most everything that we tried with xissburg is at:
http://irclogs.ubuntu.com/2010/08/14/%23ubuntu.txt
http://irclogs.ubuntu.com/2010/08/15/%23ubuntu.txt
http://pastebin.com/cPqzHj7p
http://pastebin.com/U1VjZEBp

xissburg e-mailed this followup:

I got that wubi log in temp folder. There's no boot.ini in C:\ (Win7), I only found one in XP's folder (D:\)

Here's the XP boot.ini from D:\
[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Here's the wubi log:

08-12 23:19 INFO root: === wubi 10.04 rev189 ===

08-12 23:19 DEBUG root: Logfile is c:\users\xissburg\appdata\local\temp\wubi-10.04-rev189.log

08-12 23:19 DEBUG root: sys.argv = ['main.pyo', '--exefile="E:\\Documents\\Downloads\\wubi.exe"']

08-12 23:19 DEBUG CommonBackend: data_dir=C:\Users\xissburg\AppData\Local\Temp\pylF835.tmp\data

08-12 23:19 DEBUG WindowsBackend: 7z=C:\Users\xissburg\AppData\Local\Temp\pylF835.tmp\bin\7z.exe

08-12 23:19 DEBUG CommonBackend: Fetching basic info...

08-12 23:19 DEBUG CommonBackend: original_exe=E:\Documents\Downloads\wubi.exe

08-12 23:19 DEBUG CommonBackend: platform=win32

08-12 23:19 DEBUG CommonBackend: osname=nt

08-12 23:19 DEBUG CommonBackend: language=en_US

08-12 23:19 DEBUG CommonBackend: encoding=cp1252

08-12 23:19 DEBUG WindowsBackend: arch=amd64

08-12 23:19 DEBUG CommonBackend: Parsing isolist=C:\Users\xissburg\AppData\Local\Temp\pylF835.tmp\data\isolist.ini

08-12 23:19 DEBUG CommonBackend: Adding distro Xubuntu-i386

08-12 23:19 DEBUG CommonBackend: Adding distro Xubuntu-amd64

08-12 23:19 DEBUG CommonBackend: Adding distro Kubuntu-amd64

08-12 23:19 DEBUG CommonBackend: Adding distro Mythbuntu-i386

08-12 23:19 DEBUG CommonBackend: Adding distro Ubuntu-amd64

08-12 23:19 DEBUG CommonBackend: Adding distro Ubuntu-i386

08-12 23:19 DEBUG CommonBackend: Adding distro Mythbuntu-amd64

08-12 23:19 DEBUG CommonBackend: Adding distro Kubuntu-i386

08-12 23:19 DEBUG CommonBackend: Adding distro KubuntuNetbook-i386

08-12 23:19 DEBUG CommonBackend: Adding distro UbuntuNetbook-i386

08-12 23:19 DEBUG WindowsBackend: Fetching host info...

08-12 23:19 DEBUG WindowsBackend: registry_key=Software\Microsoft\Windows\CurrentVersion\Uninstall\Wubi

08-12 23:19 DEBUG WindowsBackend: windows version=vista

08-12 23:19 DEBUG WindowsBackend: windows_version2=Windows 7 Ultimate

08-12 23:19 DEBUG WindowsBackend: windows_sp=None

08-12 23:19 DEBUG WindowsBackend: windows_build=7600

08-12 23:19 DEBUG WindowsBackend: gmt=-3

08-12 23:19 DEBUG WindowsBackend: country=US

08-12 23:19 DEBUG WindowsBackend: timezone=America/North_Dakota/Center

08-12 23:19 DEBUG WindowsBackend: windows_username=xissburg

08-12 23:19 DEBUG WindowsBackend: user_full_name=xissburg

08-12 23:19 DEBUG WindowsBackend: user_directory=C:\Users\xissburg

08-12 23:19 DEBUG WindowsBackend: windows_language_code=1033

08-12 23:19 DEBUG WindowsBackend: windows_language=English

08-12 23:19 DEBUG WindowsBackend: processor_name=Intel(R) Pentium(R) Dual CPU E220...

[Alex van der Wal (alexvanderwalathome)]

Hi Jordan,

I'd love to look for lupin-support, but yesterday, during another package
update, a new kernel got installed that somehow failed to update grub at
least that is my guess). This left me with the grub command line when
booting. That was the point where I gave up for now.

Anyway this might help.
In my case 2 partitions are involved. Windows is installed on a small
partition (i.e. "C:") and I installed Ubuntu on the large data partition
(i.e. "D:"). No RAID configuration since this is a simple laptop. Not sure
whether it matters, but there's also a recovery partition located in front
of the "C:" partition.
- Recovery (7.81 GB)
- OS_Install (43.95 GB)
- Data (414 GB)

Regards,

Alex

On Sun, Aug 15, 2010 at 5:51 AM, Jordan <email address hidden> wrote:

> Could you please check if the package "lupin-support" is installed?
> Running "apt-cache policy lupin-support" in a terminal will tell you.
>
> --
> Fresh wubi 10.04 install + package update can brick the system
> https://bugs.launchpad.net/bugs/609815
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Wubi, Windows Ubuntu Installer: Confirmed
> Status in Ubuntu: Invalid
>
> Bug description:
> Steps to reproduce:
> Install 10.04 (32-bit desktop edition) within Windows using Wubi.
> Boot Ubuntu and start a package update. This updates 'grub'.
> During the package install phase, 'grub' pops up a window that asks you
> whether or not to perform the update.
> If you do NOT choose to abort, but choose to let 'grub' update the system,
> it overwrites the windows master boot record.
>
> Result:
> This bricks the system since neither Windows or Linux boot (since both
> depend on the Windows bootloader).
> The solution is to use a recovery disk/stick to replace the MBR by a
> windows version again. This is not for everyone.
>
> So there are 2 problems here:
> - A newbie user can brick his system. Great way to popularize Linux.
> - 'grub' manages to ask difficult questions (to inexperienced users) during
> a routine package update.
>
> P.S. Sorry for the ad-hoc bug report. This needs analysis by someone who
> knows what he/she is talking about. Is this a grub, wubi or generic Ubuntu
> issue? The problem is real though.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/wubi/+bug/609815/+subscribe
>

[bcbc (bcbc)]

@Alex, I had the same issue when testing the MBR issue with the latest updates: choosing Ubuntu ends up at a grub prompt.I am assuming your wubi is on /dev/sda3 based on your comments:

This is the easy way but may not work:
grub> configfile (hd0,3)/ubuntu/winboot/wubildr.cfg

This is the long way:
grub> set root=(hd0,3)
grub> loopback loop0 /ubuntu/disks/root.disk
grub> set root=(loop0)
grub> linux /vmlinuz root=/dev/sda3 loop=/ubuntu/disks/root.disk ro quiet slash
grub> initrd /initrd.img
grub> boot

Once booted, run "sudo update-grub" and it works afterwards. (I've no idea why, since there is no apparent change in /boot/grub/grub.cfg). That's what I found on two completey different computers, with fresh 10.04 installs followed by running updates.

Just to reiterate something I found in bug 610898, when I ran the updates I purposely CHOSE to install grub to each MBR that was presented. This had absolutely no effect on the wubi which had been installed to the same partition as windows (file /host/wubildr present). But on the other, it installed grub to the MBR pointing at partition #256 on each device. So I am firmly of the belief that it is related to bug 604417.
I also believe that not selecting any device does not result in any damage.

I think the only thing related to the grub-pc update that needs to change, is that it's too confusing. In one case, a user tried to uninstall grub-pc to prevent 'future problems', not realising that it is still needed. The grub-pc screens need to describe what a bootloader is (or just hide the whole screen for wubi users).

I've heard a couple of users who reinstalled after encountering this issue, so it's not a particular nice welcome to ubuntu.

[nUboon2Age (nuboon2age)]

Question for BCBD: what if the bug is not about whether its the same partition as windows is on (because in xissburg's case it was the same partition as Windows 7) but whether it is on the first partition created or not? Because in xissburg's case Wubi was installed on a partition with the Windows 7 so Windows was definitely present, however it was the second partition created, so maybe THAT is the real key factor(?)

So the way to test this theory would be to set up a dual boot system with two windows systems. Try installing Wubi on both (especially the second windows system you create), and continue to run the experiment as you did previously. See what i mean?

[nUboon2Age (nuboon2age)]

sorry, the above question in comment #9 was directed to bcbc. ^^^

[xiss burg (xissburg)]

Hey. So, those 'steps to reproduce' are exactly what I did for this to happen.

After the installation of Ubuntu through Wubi from Windows 7, it worked fine. I got to boot in my system normally in all OSes. I ignored the Ubuntu updates in the first time, but then I decided to download and install them. During installation a GRUB Update window popped up asking whether I would like to update the GRUB. I'm a Linux noob and I didn't even know what was grub, then I chose to update it. After that I couldn't boot again. I got that same thing, "error: no such device <hex numbers> grub rescue>". Also I don't know if this makes any difference but...I have 3 partitions, D: with Windows 7, C: with Windows XP and E: just for shared files. The location Ubuntu was installed from Wubi was E:, since I usually use E: to store big files, like Virtual Box HDs for example.

The guys at #ubuntu helped me a lot throughout the whole day (Thanks :D). We tried A LOT of methods to try to fix the boot loader. But in the end, when I found some old CD-RWs and could burn the Windows 7 Recovery disc, the Windows 7 boot was recovered with one click. But I still cant boot in Windows XP and Ubuntu, I get errors when I choose any of them in the boot menu, something about corrupted or missing files.

[bcbc (bcbc)]

@ buBoo2Age:
based on xissburg's comment above, I'd say his root.disk was on E:, so /host did not contain wubildr. So I do think the issue is the same. I should probably clarify: I think the end result is the same as bug 604417 (as it should have prevented the damage), however, I don't think wubi users should even get to see the grub-pc install prompt. So, that's a usability issue as well.

Also, the latest bug you've found where installing the latest updates drops you at a grub prompt - is probably completely separate and (maybe) related to the latest kernel update (24). But that's a whole new issue :)

@xiss burg, when you install a new version of windows(7) over an old one (xp), then it uses the XP partition to install the boot files. So, likely when you ran the win 7 repair, you did more than just replace the bootloader(?), and instead let it repair win7. It's hard to say what exactly is going on though without seeing more details. Create a new thread on ubuntuforums.org and use an ubuntu live CD to run the bootinfoscript at http://bootinfoscript.sourceforge.net and paste the results. Maybe we can figure out how to get XP booting again.

[nUboon2Age (nuboon2age)]

@xiss burg, @bcbc, okay xissburg clarified something i'd not known: that on xiss burg's system Wubi was installed not on the Windows 7 partition, but on another partition that didn't have a windows system on it. So this seems to reinforce bcbc's theory that the key is installing Wubi on a non windows system partition and subtract from my alternative theory that it is related to just installing on a later partition (2nd or later) than the first created partition.

[xiss burg (xissburg)]

@ bcbc: I just posted a new thread <a href=" http://ubuntuforums.org/showthread.php?p=9735896">here</a>.

[nUboon2Age (nuboon2age)]

any news?

On Wed, Aug 18, 2010 at 11:53 AM, xiss burg <email address hidden>wrote:

> @ bcbc: I just posted a new thread <a href="
> http://ubuntuforums.org/showthread.php?p=9735896">here</a>.
>
> --
> Fresh Wubi 10.04 install + grub update renders system unbootable
> https://bugs.launchpad.net/bugs/609815
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Wubi, Windows Ubuntu Installer: Confirmed
> Status in Ubuntu: Invalid
>
> Bug description:
> Steps to reproduce:
> Install 10.04 (32-bit desktop edition) within Windows using Wubi.
> Boot Ubuntu and start a package update. This updates 'grub'.
> During the package install phase, 'grub' pops up a window that asks you
> whether or not to perform the update.
> If you do NOT choose to abort, but choose to let 'grub' update the system,
> it overwrites the windows master boot record.
>
> Result:
> This bricks the system since neither Windows or Linux boot (since both
> depend on the Windows bootloader).
> The solution is to use a recovery disk/stick to replace the MBR by a
> windows version again. This is not for everyone.
>
> So there are 2 problems here:
> - A newbie user can brick his system. Great way to popularize Linux.
> - 'grub' manages to ask difficult questions (to inexperienced users) during
> a routine package update.
>
> P.S. Sorry for the ad-hoc bug report. This needs analysis by someone who
> knows what he/she is talking about. Is this a grub, wubi or generic Ubuntu
> issue? The problem is real though.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/wubi/+bug/609815/+subscribe
>

[Orrin Zirbel (ozirbel8327)]

I'm a real newbie. Did I have this problem? I asked a question and have this reply so far:

      Your question #122771 on Wubi changed:
      https://answers.launchpad.net/wubi/+question/122771

          Project: Ubuntu => Wubi

I deleted Ubuntu from this computer and am now running Vista only again.

[nUboon2Age (nuboon2age)]

Please see bug #626503 for response to Orrin Zirbel's question. While both bugs have the Grub Update in common, the effect is different. In this one the machine is completely unbootable while in bug #626503, the Wubi install doesn't boot, but the Windows installation still boots okay.

[Mayukh (mayukh-mukherjee)]

This thread is about the issue in wubi due to grub-pc updates, but I think I should mention here some cases 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.

INSTANCE #1: (Without any updates)

A few 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 (maverick), and could boot fine.

But I was wrong. A day later I couldn't boot again, and got the same old "Alert! /host/.../root.disk not found. Dropping to shell!" followed by (initrafms) 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 (windows), sdb (ubuntu). 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, and unlike other occasions, did not run update. I shut down ubuntu. I booted again, and found myself at initrafms prompt!

In the initrafms prompt, the contents of /host were found to be same as that of sda1, i.e. C:. To make the bootloader find 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. I suspect this issue is because of a different partition of wubi than C:. If wubi was installed in C:, /host would have always had root.disk.

When I checked /dev, I could see all partitions of sda and sdb. The fact is the drives are not mounted properly.

INSTANCE OF ISSUE #2 (During install)

Although it uses the same bootloader+wubi combo as the affected ones, I gave Kubuntu Maverick a try. The issue could be reproducible even quicker. This time I got "Alert! /host/.../root.disk not found. Dropping to shell!" just after the machine rebooted for the second time during installation (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).

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

In the last one week, I have tested all ubuntu >= 9.10 as they ship with grub2. I found the issue to occur
1. after updates (9.10, 10.04, 10.10)
2. without updates (10.04, 10.10)
3. even before it is fully installed! (10.10)

Practically, almost at EVERY instance of grub2+wubi usage. The lone savior in grub2 usage is base 9.10 without updates. But I can confirm consistency 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 is therefore with th...

[Mayukh (mayukh-mukherjee)]

I think the issues mentioned in above comment (#18) correspond more to bug #626503 (https://bugs.launchpad.net/wubi/+bug/626503). Sorry for the inconvenience. I will track that bug for its resolution.