131 replies to this topic

[steve6375]

The problem is with the code in the bootsect.dat which is run on the 1st stage boot.

This can be completely avoided by installing grub4dos and running setupldr instead - then we do not have any issue!

As I show in my tutorial 102...  

[Wonko the Sane]

The problem is with the code in the bootsect.dat which is run on the 1st stage boot.

This can be completely avoided by installing grub4dos and running setupldr instead - then we do not have any issue!

As I show in my tutorial 102...  

...as long as the grub4dos MBR code is actually run by BIOS (hey, are you not the same steve6375 here? ):

http://reboot.pro/to...d-i-have-found/

 

So, possibly instead of "installing" grub4dos one could chainload grldr from BOOT.INI....

 

BTW, Wintoflash uses some "old" methods that were changed (since years, actually) where it all began:

http://www.msfn.org/...ndows-from-usb/

 

Wonko

[steve6375]

...as long as the grub4dos MBR code is actually run by BIOS (hey, are you not the same steve6375 here? ):

http://reboot.pro/to...d-i-have-found/

Yes, I am the same one that patched grubinst.exe to fix the MBR issue and the same one that includes the modified grubinst in RMPrepUSB  

 

 

Your proposal is

 

std mbr -> PBR -> ntldr -> boot.ini -> glrdr -> menu.lst -> setupldr.bin

 

instead of using just grub4dos...

 

grub4dos MBR -> grldr -> menu.lst -> setupldr.bin

 

 

Yes, replacing

 

C:\$WIN_NT$.~BT\BOOTSECT.DAT = "1st, text mode setup (Boot from flash again after finished)"

with 

 

c:\grldr="GRUB4DOS - 1st, text mode setup (Boot from flash again after finished)"

 

in the boot.ini also works (as long as you copy over grldr to the root of the USB drive and have a menu.lst).

 

Personally, I prefer to use the grub4dos boot process so I can see if there is a problem and then try to fix it. Using some XP files to boot probably breaks copyright and if there is a problem with newer h/w it is not easily fixed.

 

Guess it is just a question of what you feel most is trustworthy?  

 

 

 

 

 

 

 

[Wonko the Sane]

Guess it is just a question of what you feel most is trustworthy?  

No, it is not about "trusting" that particular patch it is about probabilities.

We have direct evidence that at least one BIOS programmer made it so that a given MBR code was not booted.

We have direct evidence that a patch kindly provided by steve6375 solves that problem.

But this tells nothing about the n other possible ways a BIOS programmer may have §@ç#ed the booting sequence.

 

I do believe that even the less neuron gifted BIOS programmer would never have delivered (or the actual PC maker accepted) a BIOS that would not boot from the two most common MBR codes, the DOS or the 2K/XP ones, that represent the two MBR codes used in (say) 97% of all PC's since 1995 and up to 2008, and possibly still more than 50% today.

 

Is it a very remote probability that a BIOS doesn't like a given  MBR code? (yes, but we have at least this Acer case ).

Is it a more remote probability that the DOS or 2K/XP MBR code has not been tested successfully? (yes, IMHO).

 

For the record, from the little we have learned/understood from the "HP patch", it is likely that also the 2K/XP MBR caused "strange behaviour", at least initially, with some BIOSes, so we may hypotize the existence of BIOS programmers without ANY neuron .

 

Most probably we should now think at the Windows 7 MBR as "the most common and that must have been tested successfully", though.

 

Please understand how there is an additional (potential) issue (as in "unusual" or "not standard") with the grub4dos "installed" which is the use of a few "hidden sectors", the fact that till now no related issue in booting were ever recorded makes this a very marginal problem.

 

You may want to acknowledge that even the good MS guys (that in theory should know what they are doing) have managed to mess BIG in writing their things as this (OT but connected in principle) experience shows:

http://reboot.pro/to...itioning-issue/

 

This case is particularly interesting, basically the good MS guys established themselves a de facto standard, suddenly changed it without checking how the previous implementation of their tools was not only incompatible, but downright destructive, with the new "standard".

 

Wonko

[Fiction]

Sometimes I feel like []

I am sorry. This is all new to me so I do not always understand the first time I read something. Or I might not remember it the first time. I forgot the 3 byte thing was mentioned. I am sorry for this :S Ill just try all of your suggestions. I'll let you know the results, also I read the two 'rabbit holes'.

 

For that specific BIOS, you evidently need only one of these (the "ignore CHS" patch), your specific issue is solved for that specific motherboard (which is good [:)] ), but the idea was to provide you with means to make the stick "more compatible" with "more motherboards", not just that specific one.

Ah, well then this is probably part of our misunderstanding. I am, right now, for the most part curious about this specific ASUS motherboard. We now know that the 4 byte patch works well, but I'd like to know why it is needed for this mobo while it is not needed for a different one. The ASUS geometry seems to be 255/63 and the drive is formatted balanced for this geometry. So why is the 4 byte patch needed then? Don't get me wrong, I'd love to learn how to get the drive as compatible as possible, but right now most of my curiosity lies with this specific motherboard. Could we focus on this first? Or is this difficult to determine?

[steve6375]

Ah, well then this is probably part of our misunderstanding. I am, right now, for the most part curious about this specific ASUS motherboard. We now know that the 4 byte patch works well, but I'd like to know why it is needed for this mobo while it is not needed for a different one. The ASUS geometry seems to be 255/63 and the drive is formatted balanced for this geometry. So why is the 4 byte patch needed then? Don't get me wrong, I'd love to learn how to get the drive as compatible as possible, but right now most of my curiosity lies with this specific motherboard. Could we focus on this first? Or is this difficult to determine?

 

Well, I agree that it is curious. Geometry seems to be correct, but maybe you could post the actual MBR, PBR and bootsect.dat from that actual USB drive that fails to boot on the ASUS?

RMPrepUSB Disk->File will do this for you, and if you use Disk Info and File Info you can also get the PBR and MBR contents nicely displayed into text files.

 

Am I correct in thinking both FAT32 and FAT16 give the problem?

Am I correct in thinking that it does not matter if you run WinToFlash to prepare the USB drive on the ASUS itself, it still fails?

 

Once I have these files, and if the CHS looks correct in MBR, PBR and bootsect.dat, then the next step would be to dis-assemble the bootsect.dat code. 

This should be identical to the PBR, except for some NOVICORP text changes and the NTLDR string being changed to $LDR$ - but we need to see it.

 

Please use the latest version of RMPrepUSB  (2.1.657) as this will parse and display PBR parameters when you use File Info on bootsect.dat.

 

Make sure you take these files from a failing USB drive, freshly prepared by WinToFlash.

[Fiction]

Am I correct in thinking both FAT32 and FAT16 give the problem?

No, there is no problem at all when using FAT16.

Am I correct in thinking that it does not matter if you run WinToFlash to prepare the USB drive on the ASUS itself, it still fails?

Yes, it still fails. However, I stopped using WinToFlash while testing this issue. In stead I format the flashdrive as a dos startup 'floppy'. Then I copy the I386 folder to the drive, boot DOS (succesfully!) and run WINNT.EXE. Now WINNT.EXE changes the bootcode to load NTLDR (also created by WINNT.EXE, allong with a boot.ini and a $LDR$) This then normally boots the setup from the bootsect.dat. The problem I am facing with this method is this: as soon as winnt.exe changes the bootsector, the device becomes unbootable on this motherboard.

 

I am quite sure that the winnt.exe changes the bootsector, then backs up the old one in a file called 'bootsect.dos'. This file can be used to boot dos right after ntldr was loaded. You can add this by writing a line for it in the boot.ini. So the old bootsector is no longer important. It is the sector made by winnt.exe that shows this behaviour. Although I do not know if all values are changed, or if some are kept in the new boot sector.

 

On the sony pc this new boot code works fine, on the asus motherboard it gives me a NTLDR not found error. It does not get to the boot.ini lines.

 

The problem I am now trying to understand is this one: the drive, prepared by winnt.exe wont boot on this ASUS but will on my sony pc. It does not matter if the winnt.exe was run on the asus mobo pc. I do think I tried formatting it on that pc as well, same thing. However, the drive set up by WinToFlash behaves very much the same. (I suspect the program mimics the things done by winnt.exe, the folder structure created looks exactly the same).

 

I cannot upload the requested data right now, I just tried something that messed up the partition. I'll parition the thing again using RMPrepUSB to create the dos part. When winnt.exe is done, I'll upload the data. Could take a few hours, not sure if I'm able to upload it today, perhaps it'll be tomorrow.

 

*edit*

Added the bootsect.dos part of the 'story'.

Edited by Fiction, 08 February 2013 - 08:57 PM.

[steve6375]

That is even weirder!

So if you copy the i386 files to the USB, boot to DOS and run Winnt on the Asus, it fails to boot to setupldr? Are you absolutely sure this is correct?

It would be good to test booting by putting the special diagnostic boot code included with RMPrepUSB on the stick and booting the Asus from that to see what you get - 

[Fiction]

Well, I'm not sure sure, but the winnt.exe runs fine all the way to the part were it asks input before reboot. And here is were it all goes wrong. The sony will boot the drive fine in this state, however the asus does not get to the boot.ini. I know this, because paching the 4 bytes of the bootsector, but NOT in the bootsect.dat allows me to at least see the boot choice menu from the boot.ini. If I do not patch the bootsect.dat, I will get the same NTLDR not found error when selecting the txtsetup entry to start booting the unpatched bootsect.dat. So:

 

bootsector not patched; asus>ntldr not found, sony>boots fine.

 

Bootsector pached but bootsect.dat unmodified; asus>reaches the boot.ini entries, but fails booting the bootsect.dat, sony> still boots fine

 

Both the bootsector and the bootsect.dat patched: both boot just fine.

 

*edit*

 

BTW, I did try running winnt.exe on the asus pc as well. Same story.

Edited by Fiction, 08 February 2013 - 09:23 PM.

[steve6375]

Well it sounds like the drive geometry on the USB drive (prepared in WIndows and so is 255/63) does not match the drive geometry from the BIOS.

If you could actually format the USB drive after booting to DOS from the Asus, then the PBR would have the correct ASUS BIOS geometry. Because the Asus BIOS geometry is not used when the FAT32 PBR is written, it probably has non-matching geometry in the PBR.

Running the TESTMBR from the special diagnostic boot code would be good to do.

 

Also, I wonder what error messages you would see if you prepare a FreeDos FAT32 USB drive and booted the Asus from it - Freedos usually complains about drive/BIOS geometry mismatch.

[Fiction]

Well it sounds like the drive geometry on the USB drive (prepared in WIndows and so it 255/63) does not match the drive geometry from the BIOS.

I agree, but the geometry command in grub4dos returned 255/63. I thought this meant the bios uses the 255/63 geometry. If not, then what was this about?

If you could actually format the USB drive after booting to DOS from the Asus, then the PBR would have the correct ASUS BIOS geometry. Because the Asus BIOS geometry is not used when the FAT32 PBR is written, it probably has non-matching geometry in the PBR.

What do you suggest? backing up the bootcode (PBR excluded) using tinyhexer, formating and then restoring it? If I just reformat the thing, then it wont be looking for a NTLDR right?

Also, I wonder what error messages you would see if you prepare a FreeDos FAT32 USB drive and booted the Asus from it - Freedos usually complains about drive/BIOS geometry mismatch.

I used freedos a while back and did not notice it, but I'll try this.

[Wonko the Sane]

Could we focus on this first? Or is this difficult to determine?

 

Sure we can focus on this .

And yes, it will be tricky , in the sense that it has already been determined: you have a mismatch of CHS induced by the BIOS, so I am failing to understand what exactly are you wanting to determine .

 

The exact behaviour has been analyzed by Legorol, here (already given link on post #4):

http://www.911cd.net...showtopic=24395

specifically for an ASUS BIOS, so I wonder WHAT exactly you are after, I thought you were missing some background knowledge to understand that thread, but now you should have them.

 

In that thread, Legorol used successfully COD11's testing MBR:

http://reboot.pro/to...code-and-grldr/

I am failing to see why you didn't ALREADY experimented with it (and report actual results/data).

 

Wonko

[Fiction]

Well, in that case, then once again I don't fully understand all of it yet. =/ sorry.

 

What is confusing me:

grub4dos geometry returned 255/63 I thought this meant that the bios was using this geometry? The drive is formatted with a 255/63 geometry, balanced.

 

If the BIOS is using a different geometry, then what would that geometry be? To what geometry should I change the drive, to make it boot-able without changing the boot-code itself.

 

After reading the referenced page again, I got even more questions (sorry once again :S):

So what I saw is that the Dell Laptop was emulating the drive to have 32 heads; this is where the problem was all along! All the tools I used seemed to have all partitioned/formatted the stick assuming 255 heads.

This seems to assume, the asus motherboard they are talking about uses a 32/64 geometry.

The Asus BIOS seems to be very smart about what geometry it emulates, and is going out of its way to try and be compatible. It is actually reading the BPB's Sectors per track and Number of heads information from the VBR, and emulates the CHS geometry to match that!

But what about the 32/64 geometry then?

Is it using this geometry to find the VBR (the VBR is the first sector of the parition right? so the bios would need to find the partiion before being able to read this?) and once it does find the VBR it starts using the values in there? Or what?

 

If this would be the same for my asus mobo, then is the following happening? The bios reads the BPB's Sectors per track in the PBP and starts using this, then it tries to find the VBR using it's default number of heads, 32 and fails to find the VBR because of the used 255 geometry. If I would find the VBR is would switch to 255 heads, because the VBR states this is being used?

 

*edit*

The toolbox zip-file at http://reboot.pro/to...code-and-grldr/ is no longer downloadable.

Edited by Fiction, 09 February 2013 - 12:07 PM.

[Wonko the Sane]

*edit*

The toolbox zip-file at http://reboot.pro/to...code-and-grldr/ is no longer downloadable.

Attached.

 

Wonko

Attached Files

•  MINI_MBR.ZIP   150.2KB   383 downloads

[steve6375]

The issue is with FAT32 - there is no issue with FAT16.

 

Maybe one easy way to see what is going on is to try FlashBoot

This post is interesting - note that the disk number reported by the BIOS is no. 0 (=floppy) and not 128 (80h - HDD) - also note that the BIOS reports H=16 S=63.

 

I have looked at the in the FAT32 BIOS and this is what it does:

 

1. Make an Int 13h AH=8 call using the drive number (L) passed to it buy the BIOS when it booted (should be 80h for HDD, but may be 0=FDD if wrong!)

2. Calculate total number of sectors on disk L  (this uses the old BIOS code - so max it can return is 1023x255x63=8GB)

3.  Ensure BPB 16-bit values at 16h and 2ah are 0000h  - which they are

4.  Get value of reserved sectors at BPB+1ch  = 63  - add 12 to it  (so we are ready to read code at 63+12)

5.  Compare the LBA address that we are about to read from the disk with total number of sectors on the boot disk calculated in step 2

6.1   If it is below then convert to CHS values and use AH=2 to read the disk sector - Note: this uses the BPB parameters at 18h (sectors per track) and 1ah (hds per cylinder) - so the values in the BPB must match what is returned by the BIOS AH=8 call or it will load the wrong sector!

6.2   If it is not below, then check if EBIOS is present - if EBIOS is present use EBIOS function Read=42h to read LBA addressed disk sector

 

The patch makes the code in red run all the time (6.1 and the check in 6.2 is not performed).

 

So what could be going wrong is that the values returned in CX and DH by the BIOS from the Get Disk Geometry call at step 1 are 0's (or at least less than 75) or possible not 255x63.

 

Another post also suggests that the grub4dos geometry command may not be displaying what the BIOS actually returns.

We need to interrogate the BIOS geometry call (AH=8). I think Flashboot does this, TESTMBR from RMPrepUSB does this (link gave earlier). and so does the code pointed to earlier by Wonko.

 

Or you could install grub4dos, add the grubutils bios utility to your stick, go the the grub4dos command line and type in

 

/bios int=0x13 edx=0x80 eax=0x0800

and see what is returned in ECX and EDX.

 

ECX=0000FEFF  EDX=0000FE02  is returned by my system for my 8GB USB drive which means  1023x255x63 which is correct.

[Motasem]

well i was stuck in this fourm for a week trying to post new thread about this but i cant dono why

 

you asking for more space while lba16 is limiting you -- right i have same problem and my sugest was this
----------

i have a bootable usb and i have installed grub loader and everything works fine

install boot in it is

7.iso

xp.iso

hbcd.iso

 

now if i load win7 iso it loades very fast without showing like winxp.iso file 16m/614m and counting untill it load all iso file in memory so i wornder why iso for win7 load without this ? and winxp.iso loades so slow so i think of something els

befor i get to this fourm i was using win2flash and it was great and fast untill i think of something called mutliboot usb so google lead me to this fourm

 

so my major question is how to integrate the win2flash winxp made files into grub ? so if the files of win2flash for winxp after extraction is like this http://grabout.com/YcRpclue

and my real multiboot usb now is like this http://grabout.com/CqM6fkdm

 

so how to copy win2flash files and make it work ( start setup of winxp extracted files )  into grub menu 

i try to make it but with too many problems and failure
the boot.ini in win2flash is this

 

[Boot Loader]
Timeout=30
Default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS
[Operating Systems]
C:\$WIN_NT$.~BT\BOOTSECT.DAT = "1st, text mode setup (Boot from flash again after finished)"
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="2nd, GUI mode setup, continue setup + 1st start of Windows" /fastdetect
C:\ = "---> DEBUG, in case of HAL.DLL or NTOSKRNL.EXE not found errors <---"
multi(0)disk(0)rdisk(1)partition(2)\WINDOWS="Debug boot rDisk 1 partition 2" /fastdetect
multi(0)disk(0)rdisk(1)partition(3)\WINDOWS="Debug boot rDisk 1 partition 3" /fastdetect
multi(0)disk(0)rdisk(1)partition(4)\WINDOWS="Debug boot rDisk 1 partition 4" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="Debug boot rDisk 2 partition 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(2)\WINDOWS="Debug boot rDisk 2 partition 2" /fastdetect
multi(0)disk(0)rdisk(2)partition(3)\WINDOWS="Debug boot rDisk 2 partition 3" /fastdetect
multi(0)disk(0)rdisk(2)partition(4)\WINDOWS="Debug boot rDisk 2 partition 4" /fastdetect

 

so what files i need to copy from win2flash setup of xp to my bootable ( grub ) flash and what lines i have to add from boot.ini so i can start winsetup without iso ?

i hope i find solution for this
 

[steve6375]

http://www.rmprepusb...ials/wintoflash

[Motasem]

this is wide complicated steve thanks for that but would you please write me here the steps you know what i have as you where with me all steps to make my flash botable

i just need to copy the winxp files as i already have them in another flash disk and i need to know what lines to add to menu.lst and one more thing my flash is already ntfs i dont want to format it lba16 i want to use it all 8g space

[Wonko the Sane]

Motasem, really, you should start a NEW TOPIC if you need assistance and NOT hi-jack other people's thread with your issues.

 

And this is the SECOND time I suggest you this:

http://reboot.pro/to...-isos/?p=167321

it's just a matter of keeping things together, so that they can be found later - if needed - and to have meaningful (and related) search results. 

 

Are you having issues with creating new topics?

 

Go here:

http://reboot.pro/fo...-boot-anywhere/

can you see a button with "Start New Topic" on it?

What happens if you click on it?

If nothing try again, this time here:

http://reboot.pro/fo...24-hello-world/

 

There might be an issue with the board , but I doubt it

 

Wonko

[Motasem]

so im at the same end for the secund time you warn me ?  man why dont you just help me i cant start new topic i have no access for that and its not my problem just tell me what to do please do me a favor

[steve6375]

this is wide complicated steve thanks for that but would you please write me here the steps you know what i have as you where with me all steps to make my flash botable

i just need to copy the winxp files as i already have them in another flash disk and i need to know what lines to add to menu.lst and one more thing my flash is already ntfs i dont want to format it lba16 i want to use it all 8g space

Did you actually read for more than 10 seconds?

 

In your case, just copy the files and folders to your USB drive and use the menu that I gave for NTFS.

[Wonko the Sane]

so im at the same end for the secund time you warn me ?  man why dont you just help me i cant start new topic i have no access for that and its not my problem just tell me what to do please do me a favor

I asked you to do something, if you do and report what happens, then I can try to call the attention of a board Admin that may hopefully solve the issue (if any).

 

You are perfectly free to hi-jack other people threads as far as I am concerned, I did not "warn" you, I tried to explain you why thread hijacking is fundamentally wrong (and unpolite), and suggested you a possible way to troubleshoot the problem.

 

Do what you see fit. 

 

Wonko

[Motasem]

im sorry i didnt mean anything wrong i have a respect for you admins and support
im testing after im done i will report like the same old time for problem of contiguse file of win7

[Motasem]

first try i copy all files from win2flash of xp setup i copy those 2 folders $WIN_NT$.~BT / $WIN_NT$.~LS

and add to my existing menu.lst this lines from your tut

 

title Install XP using WinToFlash\nStandard WinToFlash install\nSelect 1st, reboot to this menu again and select 2nd

chainloader /ntldr

 

title Stage 1 -  Install XP using WinToFlash\nUse if first menu gives NTLDR IS MISSING error after selecting 1st.

chainloader /$WIN_NT$.~BT/setupldr.bin

 

title Patch \\$WIN_NT$.~BT\\BOOTSECT.DAT\nUse this if you get an NTLDR IS MISSING error after selecting 1st.

set OS=

set BT=

# Note: this only works on FAT volumes as grub4dos cannot patch small <1K files on NTFS volumes!

if exist (hd0,0)/$WIN_NT$.~BT/BOOTSECT.DAT set BT=(hd0,0)/$WIN_NT$.~BT/BOOTSECT.DAT

if exist (hd1,0)/$WIN_NT$.~BT/BOOTSECT.DAT set BT=(hd1,0)/$WIN_NT$.~BT/BOOTSECT.DAT

if exist (hd1,1)/$WIN_NT$.~BT/BOOTSECT.DAT set BT=(hd1,1)/$WIN_NT$.~BT/BOOTSECT.DAT

if exist (hd1,2)/$WIN_NT$.~BT/BOOTSECT.DAT set BT=(hd1,2)/$WIN_NT$.~BT/BOOTSECT.DAT

if "%BT%"=="" pause --wait=3 Cannot find /$WIN_NT$.~BT/BOOTSECT.DAT && configfile /menu.lst

# detect OS

cat --skip=3 --length=0x52 --locate=FAT32 %BT% > nul && set OS=FAT32

cat --skip=3 --length=8 --locate=MSWIN4.1 %BT% > nul && set OS=FAT32

cat --skip=3 --length=8 --locate=MSDOS5.0 %BT% > nul && set OS=FAT32

if "%OS%"==""  pause --wait=3 Sorry - can't determine OS of BOOTSECT.DAT && configfile /menu.lst

echo FOUND %OS% at %BT%

cat --hex --length=0xf0 %BT%

set /p ASK=Press Y to patch file (Y/N): 

if not /i "%ASK%"=="Y" configfile /menu.lst || echo -e \n\r

echo Patched file is now...

if "%OS%"=="FAT32" cat --skip=0xe6 --locate=\x0f\x82\x4a\x00 --replace=\x90\x90\x90\x90 %BT% > nul

cat --hex --length=0xf0 %BT%

echo Finished - press a key to boot to the WinToFlash installer...

pause

chainloader /ntldr

 

----------

i restart my pc and try to boot it says ntldr is mission to back and copy ( ntldr, $LDR$, ntdetect, txtsetup.sif )  and other boot files to root of my usb dir

the secund boot i try the first line of start winxp setup from win2flash i got message says

( windows cannot start hal.dll missing or corrupt )

i try the secund line of start winxp ( the computer restarts and boot again my grub menu )

[steve6375]

You need the menu in 7.3 - under the heading 'Converting to NTFS' - there is a clue in the heading!