wubi install will not boot - phase 2 stops with: Try (hd0,0): NTFS5

Bug #693671 reported by Arsalan Afzal on 2010-12-23
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Colin Watson
grub2 (Ubuntu)
Kantarelis Spyros
Colin Watson

Bug Description

After wubi says to restart after install,when you restart to ubuntu for the first time it says looking for wubildr and just freezes there without any change after 4-5 minutes.I am using the wubi found from http://people.canonical.com/~evand/wubi/natty/ and let it download the iso.I know this is a development release and I want to help find bugs in 11.04.

bcbc (bcbc) wrote :

You can get it to install by replacing the wubildr file that comes with Natty, by one from Maverick. You have to replace the wubildr on the first partition that contains it, not just the one on your windows partition.

There are other issues getting the Natty Alpha 1 to boot:
"Bootloader install failed."
Sorry, an error occurred and it was not possible to install the bootloader at the specified location. How would you like to proceed?
* Choose a different device to install the booloader on (empty drop down box)
* Continue without a bootloader
* Cancel the installation

If you pick the second option it will complete the install, however, the grub.cfg is not created (all that is in /boot/grub is grub.cfg.new and grubenv.

After booting the installed Natty you can create a new WUBILDR and this works.

Changed in wubi:
status: New → Confirmed
bcbc (bcbc) wrote :

PS that "bootloader install failed" message occurs near the end of the Installer slideshow. That's why I added Ubiquity as an affected project. I'll leave that to someone to confirm or remove as appropriate.

In summary...
1. bad wubildr shipped with wubi.exe,
2. an exception installing grub during ubiquity install.

If you manually boot the wubi install (from the grub prompt) fix grub.cfg and rebuild the wubildr... then it works.

bcbc (bcbc) on 2010-12-23
summary: - wubi-r200 install will not boot
+ Natty 11.04 Alpha 1 - wubi-r200 install will not boot
Changed in ubuntu:
status: New → Invalid

Further info...
New Wubi installs only contain two files in /boot/grub: grubenv and grub.cfg

The problem is that when grub.cfg is generated, it fails with syntax errors. The load_video function is empty. This is because the script references a file /boot/grub/video.lst and this does not exist. But with Natty, the syntax errors result in the grub.cfg not being created - instead it spits out an error and leaves the file as grub.cfg.new.

Therefore a fresh wubi install on Natty contains two files in /boot/grub: grubenv and grub.cfg.new. Unfortunately, this makes it impossible to boot wubi unless you boot manually from a command prompt. In addition, running "sudo update-grub" always fails and grub.cfg is never created/replaced.

Note: running grub-install on Wubi to rebuild the wubildr will populate all the grub files into /boot/grub (same as for a normal install), and for Natty (for now anyway) it seems to boot although it spits out syntax errors at startup. However, when grub-install is run on Lucid or Maverick, these errors prevent the installs from booting.

New syntax checks for grub-mkconfig fails to create grub.cfg. Therefore new Natty Wubi install does not contain a grub.cfg and cannot be booted.

bcbc (bcbc) wrote :

Just tried an upgrade to Natty from Maverick using what I guess will be Alpha2. The grub.cfg generation no longer fails as script /etc/grub.d/00_header now inserts "true" into the empty load_video function. So that's good.

The upgrade doesn't clutter /boot/grub with the grub modules known to break wubi booting either. Another plus. (Although the lupin-scripts remain unchanged so the problems could occur later)

Final note: tried to do a brand new Wubi install - even though the Wubi.exe hasn't been updated since December 2010. It now fails even with the workarounds mentioned in post #1 to replace the bad wubildr. It gets into a tight loop with an error about the root filesystem has not been defined.

Jean-Baptiste Lallement (jibel) wrote :

I'm reopening the Natty task to track it in Ubuntu.

tags: added: iso-testing natty
removed: 11.04 alpha1 wubi
summary: - Natty 11.04 Alpha 1 - wubi-r200 install will not boot
+ wubi install will not boot - phase 2 stops with: Try (hd0,0): NTFS5
Changed in ubiquity:
status: New → Invalid
Changed in ubuntu:
importance: Undecided → Critical
status: Invalid → Confirmed
Jean-Baptiste Lallement (jibel) wrote :

bcbc, thanks for your investigation.

I closed the ubiquity task because its easier to deal with one issue per report. Can you file a new report against ubiquity if it's still an issue with Natty A2 please ?

Thanks in advance.

bcbc (bcbc) wrote :

No problem... I created bug 713395 for this.

Barry Warsaw (barry) wrote :

Here's what I see trying to install wubi in a Windows 7 VM (Fusion guest on OS X 10.6.6 host):

* Downloaded today's natty-desktop-amd64.iso and attached it to the VM's CD-ROM drive
* double-clicked on wubi.exe
* Choose: Install inside Windows
* AFAICT, the installation completed successfully, then asks me to reboot, which I do
* I chose to boot into ubuntu
* I see this prompt:

Try (hd0, 0): NTFS5: _

* The underline is the cursor
* The console accepts no input. I can do nothing at this point except hard-reset the VM

Barry Warsaw (barry) wrote :

FWIW, booting off the CD directly works fine and lands me in the "try-or-install" desktop.

I'm not sure where to go from here.

bcbc (bcbc) wrote :

@Barry, from my understanding, wubildr.mbr is grub4dos's bootloader, and it looks on the root of all partitions until it finds the 'rest of itself': the wubildr file. (Standard grub4dos is the grldr.mbr and grldr but you can rename these, as has been done for wubi).

The "Try (hd0,0): <file system>: " is grub4dos' standard output that it gives as it tries each partition, looking for the wubildr in the root of that partition. If it doesn't find the wubildr it outputs "No wubildr" and moves on to the next partition "Try (hd0,1):... etc.

The fact that it hangs there... this is known to occur when the partition's file system type is ext4 (because the version of grub4dos Wubi uses is old)... but in this case it appears to be something to do with the wubildr itself. If you replace it with one from a wubildr from a fresh Maverick install, it continues to start the installation.

I don't know a whole lot about wubildr, but I guess it chains grub4dos to grub2 with the core.img and some grub2 instructions to find the root.disk, loop mount it and load the grub.cfg. You can see how it gets created in the script grub-mkconfig (the version in package lupin-support), but this rebuilt wubildr doesn't contain all the grub2 instructions to support the initial installation from the windows host. It's missing this part:
if [ ${show_panic_message} = true ]; then
    if search -s -f -n /ubuntu/install/boot/grub/grub.cfg; then
        if configfile /ubuntu/install/boot/grub/grub.cfg; then
            set show_panic_message=false

Martin Pitt (pitti) wrote :

I'm afraid we just need to declare this broken for alpha-3. Moving milestone.

Colin Watson (cjwatson) wrote :

I'm working on this.

My first step was to replace Wubi's built-in copy of grldr (originally from GRUB4DOS, as noted by bcbc) with the version available in the ntldr-img grub-extras branch, which is built as an add-on to GRUB 2. (There's a little work to do to allow that to be used for Wubi, but that's the least of my worries right now.) This suffered from the same problem, but at least this way I'm working with code where I have upstream commit access and something resembling an ongoing maintenance commitment. I'm thus going to handle this as though it were a grub2 bug.

Next, having got to the point of being able to repeatedly build, install, and test modified versions of wubildr.mbr, I started trying to insert debug code. This is very difficult due to the constraints in place here. NTLDR only loads 8192 bytes from disk, and grldr must fit within that (which is why we can't just use GRUB 2 directly here, as even the most minimal GRUB 2 kernel is somewhat too big for this); it only allocates 2048 bytes for the NTFS bootstrap code, and we're very close to the limit here.

So far, I have got to the point of determining that it's calling the NTFS_Corrupt_Error function and failing. There are ten calls to this in ntfsbs.S, and I'm bisecting to find out which it is. After that I will have to figure out how to determine why. The process is very time-consuming.

affects: Ubuntu Natty → grub2 (Ubuntu Natty)
Changed in grub2 (Ubuntu Natty):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
status: Confirmed → In Progress
Colin Watson (cjwatson) wrote :

The error we're hitting is this one:

// Fix $MFT
// Input:
// DI - pointer to buffer
// BX - attr cur
        pushw %ax
        orb $NT_FG_GPOS, nt_flag

        cmpw nt_attr_end, %bx
        jae NTFS_Corrupt_Error

(The 1: label is the start of a loop, so see the source file for context if you care.)

I've checked against grub4dos 0.4.4, which seems to be the latest release. There are some differences between its ntfsbs.S and that in grub2/ntldr-img, which it probably wouldn't hurt to reconcile at some point, but none of them seem relevant to this.

Colin Watson (cjwatson) wrote :

Incidentally, it's very odd that replacing this file with one from Maverick makes any difference at all, since as far as I can make out this code has not changed in some time. There may be something weird going on there, but I suspect that investigating that will not actually turn out to be profitable in terms of fixing this for Natty - I'd rather keep going with my current investigations.

Colin Watson (cjwatson) wrote :

On entry to ntfs_fix_mmft, %di is 0x8000, %bx is 0x0020, and nt_attr_end is 0x0020.

Colin Watson (cjwatson) wrote :

I'm switching to a slightly different line of attack in an effort to preserve my sanity. GRUB's NTFS code seems to be able to handle this filesystem, and there seems to be some kind of shared ancestry between GRUB's NTFS code and ntfsbs.S; it's close enough for a side-by-side comparison in many cases. I'm working through the relevant functions and looking for interesting discrepancies.

Colin Watson (cjwatson) wrote :

This brings the assembly slightly more into line with GRUB's C code, and execution now reaches the end of wubildr.mbr. However, there's still no observable output from wubildr, so either the wrong code is being loaded by wubildr.mbr, the jump to wubildr is failing somehow, or something is failing early on in wubildr.

I'll see if I can insert a small amount of code into GRUB's startup sequence to narrow this down further.

--- ntfsbs.S
+++ ntfsbs.S
@@ -819,6 +819,8 @@ ntfs_find_attr:
        orb $NT_FG_ALST, nt_flag
        testb $NT_FG_MMFT, nt_flag
        jz 6f
+ cmpb $AT_DATA, %al
+ jnz 6f
        call ntfs_fix_mmft
        movw %bx, %si

Colin Watson (cjwatson) wrote :

GRUB's startup.S is being entered successfully. The point at which it stops working is the first transition from real to protected mode.

Colin Watson (cjwatson) wrote :

I finally got gdb working via 'target remote' and 'qemu -no-kvm'. The reason real-to-protected fails is that the relevant code is located after the offset 0x200 into wubildr, and wubildr.mbr is apparently only successfully loading the first sector.

Colin Watson (cjwatson) wrote :

I found the cause of this second problem and committed a fix to GRUB upstream:

2011-03-11 Colin Watson <email address hidden>

        * grub-core/boot/i386/pc/lnxboot.S (real_code_2): Ensure that the
        initial chunk read from the kernel always includes GRUB's multiboot
        header, which is now outside the first sector.

This successfully boots into wubildr, at last! I'm now going to go back, clean everything up, and check that the previous bug still manifests after this fix.

Colin Watson (cjwatson) wrote :

The bug I thought I'd found at first appears to no longer be relevant. I may have got something wrong at the time. I will revert those changes from my tree.

Colin Watson (cjwatson) wrote :

Evan, could you please upgrade your build system to grub-pc 1.99~rc1-3ubuntu4 once it's available, and do an updated build of Wubi? You might as well update to Wubi r205 at the same time.

Colin Watson (cjwatson) wrote :

Sorry, make that 1.99~rc1-3ubuntu5.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.99~rc1-3ubuntu5

grub2 (1.99~rc1-3ubuntu5) natty; urgency=low

  * Fix loading GRUB from lnxboot (LP: #693671).
 -- Colin Watson <email address hidden> Fri, 11 Mar 2011 13:38:53 +0000

Changed in grub2 (Ubuntu Natty):
status: In Progress → Fix Released
Evan (ev) wrote :
Evan (ev) wrote :

Ignore my previous attachment

I confirm that with the latest ISO and Wubi r205, the installation is successful.
Thanks for fixing this, impressive work!

bcbc (bcbc) wrote :

It works great for me too!

I get one error message prior to the grub menu being displayed... ' error: "prefix" is not set'

But after that it worked flawlessly. The installer seemed quicker, the bootup was very speedy, and I was surprised that Unity even worked on my machine (never did before.)

Yeah, I think we need to set prefix explicitly, and that might allow us
to build wubildr in a smarter way too; but it doesn't actually cause a
problem in practice for the time being, so I've been leaving it alone
until I have time to make sure I'm not breaking anything by changing it.

bcbc (bcbc) wrote :

There is another issue with grub.cfg on Wubi. Not on the initial install but after running update-grub. I created a new bug 738345 under lupin, but realised it's not the lupin script after all, but grub that must be causing it. I wanted to mention it here as I have no idea how to assign a bug to Grub2 after it's already created.

Colin Watson (cjwatson) wrote :

I've confirmed that this bug is no longer present in current images. I'll address other bugs separately.

Changed in wubi:
assignee: nobody → Colin Watson (cjwatson)
status: Confirmed → Fix Released
Isaac Mercer (nos-developer) wrote :

I get Kernel Panic when starting the ubuntu section of the install.

I am using 11.04 FINAL

Evan (ev) wrote :


That's an entirely different bug. Please file a bug against the linux source package:

Changed in grub2 (Ubuntu):
assignee: Colin Watson (cjwatson) → Kantarelis Spyros (kantareliss)
monolara (tarantulara) wrote :

Firstly i have to say i'm new on Ubuntu and here (i don't know if i write wrong place but it seemed similar to my problem)

yesterday i installed Ubuntu 11.10 with wubi on win7 64 bit.. then i installed some programs and all updates.. then i don't know what happened , when i choose ubuntu to start up an error message appears and black screen follows it..

it was hard to read the error because it appears and disappears so fast..

Try(..(?)...) ntfs error: "prefix" is not set

i have root.disk in correct place, i have wubildr ..

i searched internet but i couldn't find anything . So, what should i do?

thanks in advance ..

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

Duplicates of this bug

Other bug subscribers