[SOLVED] Try hd(0,0): NTFS5: No wubildr

[ago]

You can try https://wiki.ubuntu.com/WubiGuide#he...969c2d7d0ca6da

But the code is recent and has not been fully tested yet

[help_me_please]

tahnx a bunch guyz. you've been a great help.

[tinybit]

Unfortunately, grldr.mbr is already too crowded, there is no room for extra code, so can't fix it here.

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,

$MFT
$DATA (0x80) (nr,sz=132317184)
6291456+113280,118847360+7040,121304912+46224,1485 91136+47360,22049112+44528

Though MFT is as large as 132MB, but can we only read the required portion for wubildr? If possible, this could save time.

[bean123]

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.

Right, but we also need to maintain compatibility with xp, which doesn't support boot file larger than 8K.

Though MFT is as large as 132MB, but can we only read the required portion for wubildr? If possible, this could save time.

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.

[tinybit]

Right, but we also need to maintain compatibility with xp, which doesn't support boot file larger than 8K.

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.

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.

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?

[bean123]

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.

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.

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?

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.

[tinybit]

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.

No problem for 5 sectors or more.

Not difficult. Just use this directive:

#if (defined(GRLDR_MBR)) || (defined(GRLDR_INSTALL))

for a grldr.mbr, and this one:

#if (! defined(GRLDR_MBR)) && (! defined(GRLDR_INSTALL))

for grldr.

(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.

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.

Good! If we can do, why not?

[ago]

For your info I truncate grldr.mbr to 8k using dd.

[tinybit]

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.

[ago]

you can dd 8K of grldr to create your own grldr.mbr for use with boot.ini.

that is what I do (as suggested by bean123)