You can try https://wiki.ubuntu.com/WubiGuide#he...969c2d7d0ca6da
But the code is recent and has not been fully tested yet
You can try https://wiki.ubuntu.com/WubiGuide#he...969c2d7d0ca6da
But the code is recent and has not been fully tested yet
tahnx a bunch guyz. you've been a great help.
It seems this is not the case. Though grldr boot code has only a 16-sector room, grldr.mbr could have a size of up to 63 sectors. So grldr.mbr can be fixed and there is no difficulty in principle.
Another point,
Though MFT is as large as 132MB, but can we only read the required portion for wubildr? If possible, this could save time.$MFT
$DATA (0x80) (nr,sz=132317184)
6291456+113280,118847360+7040,121304912+46224,1485 91136+47360,22049112+44528
Last edited by tinybit; May 20th, 2008 at 02:42 AM.
Right, but we also need to maintain compatibility with xp, which doesn't support boot file larger than 8K.
It'd quit scanning as soon as wubildr is found, but obviously, vista put it somewhere at the end, so it has to go through the whole unused blocks.Though MFT is as large as 132MB, but can we only read the required portion for wubildr? If possible, this could save time.
At least our current grldr.mbr (of course in grub4dos I mean) has exceeded 8 KB. So patching to it will not produce new problems.
According to this, we simply can not produce a patch to resolve this issue. Can we think so?
Consider we can not skip those garbage sectors in MFT. So we cannot resolve this issue except when we put all the code into GRLDR.MBR(just as GRUB2 you mentioned above). Is that true?
It's not just size. If we expand the ntfs boot sector, it would occupied 5 sectors, this would push the ext2 code backward. Although it's possible to handle this with some #ifdef's, but I'm not fond of conditional compilation. Also, it would break the linkage with grubinst as well.
There is a trick to solve this. We can use the $INDEX_ALLOCATION attribute to get a bitmap of currently used blocks. The ntfs driver in grub4dos and grub2 already have code to handle this situation.According to this, we simply can not produce a patch to resolve this issue. Can we think so?
Consider we can not skip those garbage sectors in MFT. So we cannot resolve this issue except when we put all the code into GRLDR.MBR(just as GRUB2 you mentioned above). Is that true?
No problem for 5 sectors or more.
Not difficult. Just use this directive:
for a grldr.mbr, and this one:Code:#if (defined(GRLDR_MBR)) || (defined(GRLDR_INSTALL))
for grldr.Code:#if (! defined(GRLDR_MBR)) && (! defined(GRLDR_INSTALL))
(Note that GRLDR_INSTALL is for a slightly modified grldr.mbr embedded in bootlace.com, while GRLDR_MBR is for the independent grldr.mbr file.)
So I think no need to strip out the ext2 code. Better keep it as it is.
grldr need not be touched, because it works fine for old Windows. All we have to handle is about GRLDR.MBR. And for GRLDR.MBR, we do not mind if it could exceed 8KB, in the case of grub4dos.
Good! If we can do, why not?
For your info I truncate grldr.mbr to 8k using dd.
you can dd 8K of grldr to create your own grldr.mbr for use with boot.ini.
but the grldr.mbr along with the grub4dos release cannot be shorten to 8K. doing so will not work for you.
Bookmarks