chiark / gitweb /
mention -snapshot, thanks Tollef
authorColin Watson <cjwatson@chiark.greenend.org.uk>
Tue, 15 Mar 2011 09:29:55 +0000 (09:29 +0000)
committerColin Watson <cjwatson@chiark.greenend.org.uk>
Tue, 15 Mar 2011 09:29:55 +0000 (09:29 +0000)
ubuntu/2011-03-14-wubi-bug-693671.txt

index 1752eb7d08450d4727c54894b0ec226f271347ce..655e98dc97d7df1a33919cd9ff306cbcac55c972 100644 (file)
@@ -8,7 +8,7 @@ Wubi bug 693671
 
 <p>In a Wubi installation, NTLDR (or BOOTMGR in Windows Vista and newer) still owns the boot process.  Ubuntu is added as a boot menu option using BCDEdit.  You might then think that you can just have the Windows boot loader chain-load GRUB.  Unfortunately, NTLDR only loads 16 sectors - 8192 bytes - from disk.  GRUB won't fit in that: the smallest core.img you can generate at the moment is over 18 kilobytes.  Thus, you need something that is small enough to be loaded by NTLDR, but that is intelligent enough to understand NTFS to the point where it can find a particular file in the root directory of a filesystem, load boot loader code from it, and jump to that.  The answer for this was <a href="http://gna.org/projects/grub4dos/">GRUB4DOS</a>.  Most of GRUB4DOS is based on GRUB Legacy, which is not of much interest to us any more, but it includes an assembly-language program called GRLDR that supports doing this very thing for FAT, NTFS, and ext2.  In Wubi, we build GRLDR as <code>wubildr.mbr</code>, and build a specially-configured GRUB core image as <code>wubildr</code>.</p>
 
-<p>Now, the messages shown in the bug report suggested a failure either within GRLDR or very early in GRUB.  The first thing I did was to remember that GRLDR has been integrated into the grub-extras <code>ntldr-img</code> module suitable for use with GRUB 2, so I tried building <code>wubildr.mbr</code> from that; no change, but this gave me a modern baseline to work on.  OK; now to try QEMU (you can use tricks like <code>qemu -hda /dev/sda</code> if you're very careful not to do anything that might involve writing to the host filesystem from within the guest, such as recursively booting your host OS ...).  No go; it hung somewhere in the middle of NTLDR.  Still, I could at least insert debug statements, copy the built <code>wubildr.mbr</code> over to my test machine, and reboot for each test, although it would be slow and tedious.  Couldn't I?</p>
+<p>Now, the messages shown in the bug report suggested a failure either within GRLDR or very early in GRUB.  The first thing I did was to remember that GRLDR has been integrated into the grub-extras <code>ntldr-img</code> module suitable for use with GRUB 2, so I tried building <code>wubildr.mbr</code> from that; no change, but this gave me a modern baseline to work on.  OK; now to try QEMU (you can use tricks like <code>qemu -hda /dev/sda</code> if you're very careful not to do anything that might involve writing to the host filesystem from within the guest, such as recursively booting your host OS ... [<strong>update:</strong> Tollef Fog Heen points out that you can use the <code>-snapshot</code> option to make this safer]).  No go; it hung somewhere in the middle of NTLDR.  Still, I could at least insert debug statements, copy the built <code>wubildr.mbr</code> over to my test machine, and reboot for each test, although it would be slow and tedious.  Couldn't I?</p>
 
 <p>Well, yes, I mostly could, but that 8192-byte limit came back to bite me, along with an internal 2048-byte limit that GRLDR allocates for its NTFS bootstrap code.  There were only a few spare bytes.  Something like this would more or less fit, to print a single mark character at various points so that I could see how far it was getting:</p>