Jump to content











Photo
- - - - -

xp setup: ntldr not found, but boots fine on newer motherboard


Best Answer Wonko the Sane , 10 February 2013 - 12:23 PM

Try writing these values in the partition table:

0C-80-1023-254-63-1023-254-63-63-7566552

:unsure:

 

BTW, till now we are exactly in the situation described by the originally referenced post, if for *any* reason the ASUS bios does not "like" the partition table or the geometry reported by the device, it will automagically determine a suitable geometry, disregarding the values in the PBR BPB.

 

In Legorol's case the "determined" Head number was 64, in your case it is 128.

This must be connected to the size of the device, Legorol was using a 1Gb stick, you are using a 4 Gb stick.

It makes sense:

1024*64*63*512=2,113,929,216

1024*128*63*512=4,227,858,432

 

As a matter of fact these geometries are easily replicable in Qemu (+Qemu manager), whose (Bochs originated) BIOS is a "strict" one.

 

:cheers:

Wonko

Go to the full post


  • Please log in to reply
131 replies to this topic

#1 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 17 January 2013 - 10:59 PM

This is basically a followup of this topic: http://reboot.pro/to...ny-suggestions/

 

But here I'll try to ask a more specific question. I'll do this in a different topic, because the question is slightly different and because the question I asked there was answered.

 

This is what I did:

1 I used the HPformat tool (HPUSBFW.exe) to create a bootable dos usb flashdrive.

2 I copied the following files to the flashdrive:

        CDROM\OAKCDROM.SYS

        CONFIG.SYS

        EMM386.EXE

        HIMEM.SYS

        smartdrv.exe

3 I copied the I386 folder from a windows install cd to the flashdrive

4 I boot the flashdrive

5 started smartdrv and after that the I386\winnt.exe and continued the dos part of the installation.

 

The next part (txtsetup) from the installation booted fine on the motherboard of my sony vaio VPCW21S1E,

but trying to boot this on asus a7v8x-mx motherboard I get a 'NTLDR is missing' message      

 

I did this to debug the boot process. I will repeat this: I am NOT trying to make a functional setup USB in this fashion. In the previous topic Sha0 told me the setup would probably not work unless forcing the drivers to load in an early stage, so I am aware of this. I just want to know where this difference comes from.

 

Normally I would use Novicorp WinToFlash (it basically does the same thing WINNT.EXE does, but perhaps it does fix the possible driver issue as well). I noticed it would not work with the asus motherboard on the default FAT32 LBA setting. It only worked with this asus motherboard when I set the program to format the drive FAT16 LBA.

 

In the previous topic I thought the FAT16 option worked because the partition would then automatically be smaller then 2GB. I was thinking of a capacity limitation, but if you read the previous discussion, you will see we ruled this out.

 

Now after some googling I found this: http://wintoflash.co...0&t=32&start=0.

 

NTLDR is missing message mean the partition boot record can't find NTLRD file on partition. May be FAT16 may help to fix this - FAT16 partition boot record is smaller and more simple...

 

Does anyone here know why this motherboard will only load the xp txtsetup when using FAT16, while dos boots perfectly from FAT32?

 

Do you think I will be possible to make a bookable flash drive, containting a xp setup with a size of more then 2GB? It really annoys me that I need to throw away most of the flashdrive's capacity, so I can use it on all op my computers independent of specs.

 

*edit* added some extra details, to be more specific and avoid confusion.


Edited by Fiction, 17 January 2013 - 11:07 PM.


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 17 January 2013 - 11:12 PM

Try different formats using RMPrepUSB and selecting FreeDOS

 

1. FAT16 2GB  FreeDOS (no overrides) , 5 Freedos folder

2. AS above but add Boot as Hdd (2PTNs) override

3. FAT32 FreeDOS (no overrides) , 5 Freedos folder

4. as 3 but add Boot as Hdd (2PTNs) override

 

Report back after trying all of these on all systems.



#3 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 18 January 2013 - 01:03 AM

Have you tried WinSetupFromUSB and the auto-format option, which uses FBInst, which is considered quite suitable for picky BIOS-es?

Try 1.0 beta8, use auto-format option, use NTFS or the other file systems and options presented if need to.

If you are into testing bootability only, you don't have to select any other options in the program.

 

This way you will end up with USB stick partitioned and formatted by FBInst in its special way, an option upon boot whether to continue to Grub4dos or launch PLoP boot manager, and if nothing was selected you will get to grub4dos command prompt.

PLoP is also a good option to try on picky motherboards, should you be able to start it.

 

Alternatively, there is FBInstTool, which also uses FBInst internally, but it could be a bit trickier for you to get going.

http://code.google.c...-2012-12-21.zip

http://bbs.wuyou.com....php?tid=189221


  • laddanator likes this

#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 January 2013 - 05:25 PM

You are likely to be hitting a whole range of issues this way.

That approach (you are perfectly free to take for good my word for it or completely ignore it, of course) makes very little sense as a "debug method".

 

Of ALL the available methods to partition a USB stick, as you were already told, BTW, the HP USB Format utility is NOT the one to use (as we have better tools and more "granular" control of what happens):

http://reboot.pro/to...tions/?p=165830

 

So I will have to ask:

WHAT EXACTLY is your GOAL? :unsure:

 

If it is to actually install the XP to a given machine, then use this one (tested, very similar to the one you are now testing, but fully working) WINNT.EXE based approach:

http://www.911cd.net...topic=16713&hl=

 

Otherwise, do the following:

Right after the running of HPUSBFW.exe copy to the root of the stick:

  • NTLDR
  • BOOT.INI (*any* boot.ini will do, if needed it will be edited later)
  • NTDETECT.COM
  • grub.exe and grldr <- get these from last "featured" build on chenall's page: http://code.google.c.../downloads/list

then copy the other DOS files you mentioned

Edit BOOT.INI and add to it a line like : C:\grldr="grub4dos"

Boot the stick (to DOS) and on command line run grub.exe

At the command prompt enter:

 

 







chainloader /ntldr
boot

Try selecting the grub4dos entry in boot.ini.

At the grub4dos command prompt enter:

 

 

 







chainloader /io.sys
 boot

If everything works as expected you will be back to DOS.

This time you will have a bootable stick that besides DOS contains grub4dos that can be used to inspect the contents of the source and target disk/exchange disks/do more things like checking geometries and what not (i.e. putting you in a condition to actually "debug" something).

 

About BIOS limitations and FAT16, 32 etc, read the USB FAQ #10 here:

http://jaclaz.alterv...SB/USBfaqs.html

AND read here:

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

why exactly the HPUSBFW utility is NOT advised (and incidentally :w00t: the EXACT answer - most probably - to your EXACT issue related to an Asus BIOS ;) or however a related report and a working "debug/test" method/tool)

 

:cheers:

Wonko



#5 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 19 January 2013 - 12:20 AM

@steve6375

I would like to try your approach first. However, do you want me to just test if I can boot into freedos or do you want me to run winnt as well?

smartdrv does not work with freedos, or so it seems, therefore it takes ages for winnt.exe to complete. It is the NTLDR boot-loader that is of interest here, since the noted behaviour only applied to this loader. See below for more details.

 

@ilko

That looks promising, I might have a look into it, but for now I am curious about steve6375's idea.

 

@Wonko the Sane

Ah, we meet again :P

I hoped I was being clear and specific enough this time, but it appears my intentions are still vague.

I'll try to explain the 'goal' a bit better. See below.

 

A few days back I used Novicorp WinToFlash to transfer a xp installation source onto a usb drive and noticed it would boot just fine on my sony notebook, but would not work on the asus mobo pc.

 

So now, there are actually 2 goals:

1 learn something about motherboard specificness when booting: why this difference?

2 get the asus mobo computer to boot into a windows xp usb drive with a partition larger then 2GB, unless I know for sure this is not possible.

 

Like I said in the intro: the asus mobo boots dos just fine, both FAT16 (2GIB) and FAT32 (max size), I then ran smartdrv to reduce install time and ran winnt.exe.

 

Both computers started winnt.exe just fine, but when it completed it asked to reboot, in order to boot the new NTLDR it installed. This is where the difference gets noticed: the sony pc boots the NTLDR just fine, but the ASUS mobo pc would only boot from it when formatting the partition as FAT16. At first I thought using FAT16 worked just because after formatting FAT16 the partition would be smaller then 2GiB. However in the previous topic we excluded the possibility of a partition size limitation being involved.

Now in my first post of this new thread, you could read why I'm now thinking the FAT16/32 difference has something to do with it: according to the WinToFlash treat a FAT16 MBR is smaller and less complex.

 

It is still weird however, FAT32 boots to dos just fine, but booting the NTLDR fails when using FAT32 on the asus mobo pc.



#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2013 - 01:28 AM

Both computers started winnt.exe just fine, but when it completed it asked to reboot, in order to boot the new NTLDR it installed. This is where the difference gets noticed: the sony pc boots the NTLDR just fine, but the ASUS mobo pc would only boot from it when formatting the partition as FAT16.

Do you mean that after winnt.exe and reboot, you are rebooting from the internal hard disk - and it is at this point you get the 'cannot find ntldr' message?

 

What do you format the internal HDD as (FAT32, NTFS) and is this done manually or do you have a winnt.sif or some other automation method?



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 January 2013 - 11:48 AM

 Now in my first post of this new thread, you could read why I'm now thinking the FAT16/32 difference has something to do with it: according to the WinToFlash treat a FAT16 MBR is smaller and less complex.
It is still weird however, FAT32 boots to dos just fine, but booting the NTLDR fails when using FAT32 on the asus mobo pc.
Well, what you still seem to miss is that - as posted - this is one of the most known issues, and it most probably has to do with disk geometry, conflicting CHS/LBA or possibly a specific quirk of that Asus BIOS.

Do take some time reading the given links, BOTH the possible "causes" and hopefully some "remedies" are provided in them.

As well, the thread on 911CD should give you an idea of what to check and how, right now your "useful for debug" setup (with no offence whatsoever intended :)) is simply not "good enough" to provide you meaningful "debug" details.

Do prepare the stick as suggested and try using it, with the sequence of operations that you provided.

In theory the USB stick gets drive letter C: and the partition on the internal hard disk will get drive letter D:.
Then, when you install through WINNT.EXE the C: wiil be "boot" volume (what MS calls the other way round "System") and D: will be "system" volume (what MS calls the other way round "boot"), consequently the NTLDR will be copied to C: and not to D:.
See also (only seemingly unrelated):
http://www.multiboot....uk/system.html

It is possible that this does not happen on the Sony motherboard (which will mark the Sony as "queer" BIOS) but it does on the Asus one (in which case the Asus BIOS is "normal"), but I suspect that you are rebooting with the stick still attached, in which case the Asus "smart" geometry guess coupled with the UNbalanced partitioning the HP USB tool makes will play a role in it (and be the actual cause).
Since you did not provide enough details, I cannot say more.


:cheers:
Wonko

#8 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 19 January 2013 - 01:08 PM

Perhaps I'm still not being specific enough.

 

Right now we are not doing anything with the internal drive. The winnt.exe copies the temporary files to the usb device and replaced the dos boot-loader (on the flash drive!) with the NTLDR bootloader. The internal drive is only accessed during the txtsetup phase, where we are presented with the option to repartition and select a partition on which to install xp. There does not seem to be any difference in content when the winnt.exe ran on the asus mobo or on the sony one. In both cases there actually is a NTLDR file on de flashdrive. However on the asus mobo the NTLDR simply wont load for some reason.

 

If I run the WINNT.exe on the asus mobo, it will boot just fine on the sony mobo when finished, but the asus mobo will tell me that 'NTLDR is not found'.  But I know it is on the flash drive when this error is being displayed.

 

This, however, does not happen when I used FAT16. I think there is something wrong with the way the asus mobo is interpreting the FAT32 MBR. But for some reason this is not a problem when booting dos. Because of this, I thought that maybe hexediting the MBR (after winnt.exe is finished) would make it bootable on the asus mobo, but my knowledge of assembly is limited and I would not know where to start.

 

I hope the behaviour is more clear to you guys now.

 

I will read the links, but first I'd like to be sure we understand each other, to avoid reading long pages of content I might not be interested in.



#9 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2013 - 02:43 PM

So are you saying that the same USB stick, formatted to 1.8GB as FAT16 works, but when formatted as FAT32 and 1.8GB does not boot on the Asus?



#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2013 - 03:17 PM

Experiment

1. Ensure the BIOS on the Asus is set to boot from USB HDD and not USB-ZIP

2.Take your FAT32 pen which does not boot on the Asus but does boot on the Sony, install grub4dos onto it (e.g. use RMPrepUSB or grubinst and add grldr), boot it and go to grub4dos console (type c) - then type   blocklist /ntldr - and also geometry  what result do you get? Try on both systems and for FAT16 and FAT32.

 

P.S. Did you try formatting as FAT32 on the Asus, copying the files, rebooting on the Asus to do the first phase, and then rebooting on Asus for the 2nd phase.?

 

P.P.S. You can view head and sector parameters of MBR and PBR by using RMPrepUSB  Drive_Info  (use 0 for MBR and P1 for PBR).



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 January 2013 - 04:01 PM

I will read the links, but first I'd like to be sure we understand each other, to avoid reading long pages of content I might not be interested in.

Well, no. :(

So now, there are actually 2 goals:
1 learn something about motherboard specificness when booting: why this difference?
2 get the asus mobo computer to boot into a windows xp usb drive with a partition larger then 2GB, unless I know for sure this is not possible.


You are coming here asking for support and saying that you want to learn, if you choose the RED pill, there is a price for it. (and rabbit holes may be deeper than what you might think)

Rest assured that by reading attentively the given links you will not only learn something USEFUL, you will also understand WHY exactly that is happening, how to verify WHAT is happening AND HOW to solve the issue (which BTW is partially due to the wrong choice you made for the USB partitioning/formatting tool).

 

 

And these are not "long pages":

About BIOS limitations and FAT16, 32 etc, read the USB FAQ #10 here:

http://jaclaz.alterv...SB/USBfaqs.html

AND read here:

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

why exactly the HPUSBFW utility is NOT advised (and incidentally :w00t: the EXACT answer - most probably - to your EXACT issue related to an Asus BIOS ;) or however a related report and a working "debug/test" method/tool)

they are a single FAQ/FGA and a single thread, made of 14 (fourteen) posts of which only the first 12 (twelve) are actually relevant (and they are VERY relevant) to your issue.



:cheers:
Wonko



#12 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 19 January 2013 - 04:32 PM

Ok, I am sorry if I sounded a little lazy. I just wanted to make sure you guys understand the fact that winnt.exe only effects the flashdrive itself, not the internal disk. (As far as I can tell.)

 

You are, of course, completely correct: I'll take that darn red pill :P. I'll read all of it. After that I'll report back.



#13 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 19 January 2013 - 07:37 PM

Ok, apparently I waited for to long and my edit button disappeared. Sorry for the double post.

 

@Wonko

 

I am terribly sorry. I thought you where not understanding me correctly but in fact you were spot on. This 911cd topic is indeed about a similar problem.

 

First I read http://jaclaz.alterv...SB/USBfaqs.html

the FAQ seems for the most part focused on booting a xp INSTALL from usb and why this is not possible. Note however that

I just want to boot the setup, not xp itself.

FAQ #10 seemed more usefull but very empiric. It basically states 'if it does not work in a certain way, try a different

one'. It lists a lot of possible 'variations' to try, but I'm not sure whether I am dealing with any of these.

 

Then I started reading the http://www.911cd.net...showtopic=24395

I noticed directly that my knowledge of assembly is not 'limited' but nearly 0. That's probably why I disliked reading it at first (I did already read that FAQ).

I did not understand all of this, but let's see what I did understand.

 

One of the first links in the thread is: http://blog.clemens....dows_3170.html.

It basically states (I think) that there is something wrong, or 'not smart' in the windows boot loader:

The generic method contained in the boot loader to read a sector from disk is "clever" as it checks whether the sector is below the maximum sector index that is reachable with the CHS geometry reported by the BIOS. If not, it uses the LBA interface of the BIOS. If yes, the cleverness of the boot loader suddenly vanishes. Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block. That's a section of the first sector embedded into the boot loader that hard codes such values as head per cylinder and sectors per heads into the boot loader. If the hard coded values are different from the ones used by the BIOS, the calculation produces wrong values. So, if you move your partition to a BIOS that exposes a different geometry to the boot loader than is hard coded in the boot loader the whole thing blows up. Brilliant Microsoft design, as ever.

This could explain why the the error started when the NTLDR was installed: this boot loader is more sensitive to LBA/CHS differences.

Further:

If you have "balanced data" (meaning that NO matter if you use CHS data or LBA data you always have the same start and end sector) you won't need most (if not all) of these patches, AND some BIOSes may be "sensible" to "orthodox" partitioning, i.e. having both beginning and end sector on Cylinder and Head boundary.

Not completely sure what it means to 'always have the same start and end sector' but according to this forum, some BIOSes (possibly mine) are sensible to this.

 

Not sure how this is linked together but it seems quite possible that is is a LBA/CHS issue (damn I barely know what their difference is) and possibly both the asus mobo and the NTLDR type boot record are sensitive for this. This must be why it only goes wrong when both issues 'meet' at the same time.

 

Possibly it could work if I formatted the volume in a LBA/CHS 'balanced' way, something the HP tool does not do.

 

I am sorry, I read it all but I do not understand all of it. Could you translate this to a 'lower level' or do you know an other article to boost mine?

 

 

Would RMPrepUSB do format 'balanced' or do I need http://reboot.pro/to...tch-001-alpha/, as I have no idea how to use this.

 

Could I somehow use tinyhexer to check whether or not the drive has been formatted 'balanced'?

 

@Steve

 

So are you saying that the same USB stick, formatted to 1.8GB as FAT16 works, but when formatted as FAT32 and 1.8GB does not boot on the Asus?

That's almost what I'm saying but not exactly. Both of them work when booting to dos, but when winnt.exe finishes the flashdrive no longer boots to dos, it boots onto the NTLDR that the winnt.exe placed on the flash drive. The sony boots this NTLDR fine, the asus tells me 'NTLDR not found'.

 

*edit* however, I must admit I did not try the <2Gib and FAT32 combination yet, since I was using the HP tool and otherwise WintoFlash, both are limited in their options.

 

I'll try using RMPrespUSB now. If it formats 'balanced' perhaps the whole 'problem' will be gone, so I'll first try a maximum size parition.


Edited by Fiction, 19 January 2013 - 07:44 PM.


#14 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 19 January 2013 - 08:14 PM

There is no reason for a BIOS on one motherboard to use the same C/H/S geometry for a USB storage device as another BIOS on another motherboard.

 

If you have code on the USB storage device (such as the code the winnt.exe is installing) that uses C/H/S geometry information, then switching BIOSes risks having that code malfunction, as the geometry might not be the same.  The solution is simple: Either do not use code that cares about this geometry information, or do not switch BIOSes. :)



#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2013 - 08:27 PM

There is no reason for a BIOS on one motherboard to use the same C/H/S geometry for a USB storage device as another BIOS on another motherboard.

 

If you have code on the USB storage device (such as the code the winnt.exe is installing) that uses C/H/S geometry information, then switching BIOSes risks having that code malfunction, as the geometry might not be the same.  The solution is simple: Either do not use code that cares about this geometry information, or do not switch BIOSes. :)

That was what I was trying to prove :dubbio: . Also, it may be that if the USB drive was prepared using the Asus, and then booted and tested on the Asus, it might then work on the Sony...



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 January 2013 - 08:32 PM

@Fiction

The Faqs have a date of release (and you were explicitly pointed to #10 only).

We did learn something new in the meantime ;), but you cannot get the basics without getting the basics (and have a quick look at history).

A working solution (though not particularly elegant :blush:) was found at the time, see the "companion page":

http://jaclaz.alterv...B/USBstick.html

 

You may use Tinyhexer (possibly with my MBRview structure viewer):

http://reboot.pro/to...-hexer-scripts/

 to read the (most probably wrong) data the HP USB tool  wrote in your stick partition table, then use this (still mine) worksheet to verify/check/play with numbers: 

http://reboot.pro/to...a-translations/

get the updated v2 from here: http://reboot.pro/to...ations/?p=74116

 

Anyway, you understood most of the given resources correctly :thumbup:.

 

There are several different issues that may play a role, in your case as per the given link it is very likely it is a "quirk" of the Asus BIOS.

 

To get another idea of what happens when two BIOSes disagreee on the geometry of disk device, check this thread (again only seemingly unrelated):

http://www.911cd.net...topic=23408&hl=

 

Some additional (interesting) innfo related to:

http://blog.clemens....ndows_3170.html

can be found here (when we actually gained knowledge of the above):

http://www.911cd.net...91

 

:cheers:

Wonko



#17 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 20 January 2013 - 11:25 AM

@Sha0 & steve

Does this mean I should run winnt.exe on the asus, or should I format the drive on the asus as well?

 

@Wonko

I'll play with the four byte MBR patch for a while (in combination with running winnt.exe on the asus)

I really like be able to understand when a device has been formatted 'ballanced' and how I should fix this myself.

This: http://jaclaz.alterv...B/USBstick.html is still a bit hard for me and btw most of thos utilities are no longer available using those links.

I still have a difficult time knowing what all involved values in MBRview are (lol @ Kansas City Shuffle) and what they should be.

 

I guess I'll re-read http://jaclaz.alterv.../USBstick.html, since it IS explained in there. Perhaps I can ask a more specific question about the first thing I do not understand.

 

Interesting as it might be to do this manually once, this seems like a lot to do each time I need to boot somehting.

Is there no utility to format the thing correctly in one go?

 

Perhaps I should try this guy http://reboot.pro/to...atch-001-alpha/ after all?

 

Do know that my forum activity will drop soon, since my study will start asking a fair amount of my time. I will continue to read posts on this thread, however I might not be able to respond on a daily basis. I hope this will not be a problem.

*edit*

I tried this: formated the drive using RMPrepUSB on my sony pc, then ran winnt.exe on the asus pc. When completed used tiny hexer to patch the 4 bytes. Result: it reads the contents of the boot.ini, and displays is, but when I try to pick the install option

C:\$WIN_NT$.~BT\BOOTSECT.DAT = "Windows XP Installation/Upgrade"

I once again get the 'NTLDR is missing' message.

 

I'll try playing with the boot.ini content.

 

*edit2* most noticeable thing I got when changing the boot.ini was a hal.dll error.

It looks as if NTLDR switches back to CHS even with the four bytes patched. I'll try formating the device using the asus pc, but I think 'balancing' the drive has a greater chance.


Edited by Fiction, 20 January 2013 - 12:05 PM.


#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 January 2013 - 03:37 PM

Well, here we have a problem. :ph34r:
There is NO "4 bytes MBR patch" that I can recall.
There are two different 4 bytes PBR (or bootsector) patches, one for FAT32 and one for NTFS.

 

And a "3 bytes" MBR patch (actually originated by the HP USB format utility) which we didn't talk about specifically (but that is linked in one of the given pages on 911CD):
http://reboot.pro/to...s-info/?p=14607

 

The essence of balanced CHS/LBA is the following (do play a bit with the given CHS/LBA translating spreadsheet).

 

In a partition table the SAME (objectively) data is written TWO times according to TWO different standards.

Scope of a partition table entry is to univocally identify a "region" of the disk.

 

The CHS standard identifies a region by mentioning WHERE it starts and WHERE it ends.

The LBA standard identifies a region by mentioning HOW MANY sectors are before it's start and HOW MANY sectors is the region long.

 

The CHS uses as units sectors BUT uses them along a convention that "groups" sectors into "heads" and that groups "heads" into "cylinders".

Think of the normal decimal system we use, you know that when you sum 9+1 you get 1 ten and  that when you sum 99+1 you get 1 hundred.

The nice part of the decimal system is that "groups" like ten or hundred contain ten times the lesser level "group".

With CHS you have to take into account the geometry, i.e. the max number of items available, just like when you make 9+1 you are sayin that you have 1 ten and 0 units, BUT the max number of items available is not "standard" and can vary.

Please follow me.

If you had a "fictional" disk that had 10 sectors per head and 10 heads per cylinder, you would call first sector 001, second one 002, etc. ninth one 009, tenth one 010, eleventh one 011, etc.. ninetyninth one 099, hundredth one 100, etc.

Let's try writing the above in HTU notation (Hundreds/Tens/Units), you would have 0/0/1, 0/0/2, 0/0/9, 0/1/0 0/1/1 0/9/9 and 1/0/0.

But  if you had a "strange" numerical system where a ten is made out of 32 units and a hundredth was made of 64 tens, what would happen?

Sector #32 would be 0/0/32, #33 0/1/1, sector #2047 (64*32-1=2047) will become 0/63/32, #2048 1/0/1.

So, let's say that you have a partition that starts on sector #33, it will be expressed in a geometry of n/64/32 as 0/1/1.

If it is 2016 sectors in size, it will end on sector #2048, i.e. on 0/63/32.

 

Now let's see LBA.

How many sectors are before sector #33? Obviosly 32.

How many sectors are in the partition? Obviously 2016 /we decided by design this number).

 

Congratulations, you have a valid, balanced partition table entry:

0/1/1 - 0/63/32 - 32 - 2016

(you can use EITHER of the TWO addressing methods to identify EXACTLY the SAME region on disk)

 

BUT while the LBA addresses will remain the same NO MATTER which geometry is used (how many units make a ten and how many tens make a hundred) the CHS do NOT.

If you write that same partition entry on a device with a geometry of (say) n/16/63 what would happen?

The beginning is NOT anymore 0/1/1 but raher 0/0/33.

The end is NOT anymore 0/63/32 but rather 0/32/32.

On this device the SAME partition area will be expressed as:

0/0/33 - 0/32/32 - 32 - 2016

 

  I hope this makes it more clear.

 

Now a question for you.

What do you think that EXACTLY is C:\$WIN_NT$.~BT\BOOTSECT.DAT? (i.e. what are it's contents? Try opening that file with tinyhexer and have a look at it)

 

:cheers:

Wonko



#19 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 20 January 2013 - 11:32 PM

I need to get out early tomorrow so I wont be able to have a detailed look at your last post until at best tomorrow evening or at worst Wednesday. However I'd like to say something about this

 

Well, here we have a problem. :ph34r:
There is NO "4 bytes MBR patch" that I can recall.
There are two different 4 bytes PBR (or bootsector) patches, one for FAT32 and one for NTFS

 

I guess I meant the PBR. I read http://en.wikipedia....ter_boot_record and am now aware that there are multiple bootsectors and that the MBR is the fist sector (do I understand correctly?). I am sorry I am wasting your time with my noobishness. I am sure you spend enough time explaining trivial things to noobs as is. It is really appreciated however.

 

I jumped a bit ahead and took a look at the bootsect.dat. I was to curious to wait for tomorrow with this.

It seems like it contains a FAT32 bootsector. 'bootsect' I guess it should have rung a bell.

It is all there even the UNMODIFIED! 4 bytes I patched in the boot-sector on the drive itself... It seems worth a try to NOP these too...

 

*edit*

I still need to read your 'balancing tips' in your previous post. However I wanted to tell you that I could not wait to try NOP-ing the bytes in the bootsect.dat and it actually worked :P

 

I was able to successfully boot the txtsetup on a maximum size FAT32 partition on the asus FOR THE FIRST TIME. So we (aka you) are definitely on the right track: this IS a CHS issue indeed.


Edited by Fiction, 20 January 2013 - 11:43 PM.


#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 January 2013 - 10:05 AM

....
I was to curious to wait for tomorrow with this.
....
However I wanted to tell you that I could not wait to try NOP-ing the bytes in the bootsect.dat and it actually worked :P
 
I was able to successfully boot the txtsetup on a maximum size FAT32 partition on the asus FOR THE FIRST TIME. So we (aka you) are definitely on the right track: this IS a CHS issue indeed.

Yep :thumbsup:
Curiosity - besides killing the cat :w00t: - does give some small satisfactions from time to time. ;)

Wrong attitude:

Spoiler

 

Right :thumbup: (though dangerous :ph34r:) one:

Spoiler

 

 

Don't worry :), it does take some time to get all these pieces of info and assemble them together in a "valid" picture.

 

 

:cheers:

Wonko



#21 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 21 January 2013 - 01:44 PM

You could always patch the file using grub4dos, if you reboot to grub4dos before it boots from the HDD

title Patch \\$WIN_NT$.~BT\\BOOTSECT.DAT

set OS=
set BT=
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=8 --locate=MSWIN4.1 %BT% > nul && set OS=FAT32
cat --skip=3 --length=8 --locate=MSDOS5.0 %BT% > nul && set OS=FAT32
cat --skip=3 --length=4 --locate=NTFS %BT% > nul && set OS=NTFS
if "%OS%"==""  pause --wait=3 Sorry - can't determine OS of BOOTSECT.DAT && configfile /menu.lst
echo FOUND %OS%
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
if "%OS%"=="NTFS" cat --skip=0xd9 --locate=\x0f\x82\x3a\x00 --replace=\x90\x90\x90\x90 %BT% > nul
if not "%OS%"=="" cat --hex --length=0xf0 %BT%
echo Finished - press a key to continue...
pause

 



#22 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 21 January 2013 - 09:26 PM

@Wonko

I read your post. I'm not sure I understand correctly when it is NOT balanced then.

 

I looked at the worksheet, but it is not intuitive to me what values I should put in there myself and what once should be calculated automatically. About the value's I should put in there myself: how should I determine those? Preferably I'd use windows 7/xp compatible software while running these systems (if possible). I guess I could use your MBRviewer script for tiny hexer to help me write the worksheet values onto the bootsectors?

 

@steve

Interesting, I did not know I could patch files using grub4dos. However I have access to a second computer so this should not be necessary.



#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 January 2013 - 10:50 AM

@Wonko
I read your post. I'm not sure I understand correctly when it is NOT balanced then.

In the example posted, imagine that you have this entry:
0/1/1 - 0/63/32 - 32 - 2016
As seen, this is perfectly "balanced" on a BIOS that detects the device as m/64/32.
This means that IF the BIOS uses CHS only (let's say with a partition type of 06 - FAT 16 CHS mapped) it will find the PBR on first sector of the second cylynder, i.e. 32*1+1=33: it's the 33rd sector.
Of course IF the BIOS uses LBA only (let's say with a partition type of 0E - FAT 16 LBA mapped) it will find the PBR after 32 sectors, i.e. 32+1=33: it's the 33rd sector.
But what happens on another BIOS that sees the device as having a geometry of n/16/63?
For LBA there are NO issues, as 32+1=33: it's still the 33rd sector.
For CHS the first sector of the second cylinder suddenly becomes 63*1+1=64: it is the 64th sector, of course since NO PBR is there in this BIOS it won't be found.

The SAME partition entry will be "balanced" on a m/64/32 geometry BUT unbalanced on a n/16/63.

 

BUT what the HP USB Format utility often does is something slightly different.

Let's assume that the hypothetical device does have a n/16/63 geometry and a total capacity of 3180 :w00t: sectors.

The HP utility will try to use ALL available sectors, so the LBA part will be obviously "63-3117".

The PBR will have this data:

  • sectors before 63
  • total sectors 3117
  • number of sectors 63
  • number of heads 16

But what happens to the CHS?

The starting triplet is easy, it will be 0/1/1.

The ending one will be tricky. :dubbio:

The CHS on n/16/63 corresponding to LBA "63-3117" (try making it on the spreadsheet) is 3/2/30.

BUT the HP formatting utility uses "orthodox" partitioning where a partition should alway end on a cylinder boundary.

The highest cylinder boundary BEFORE 3/2/30 is (obviously) 2/15/63, and this is the value that the HP tool will write.

So you will have a partition table of:

0/1/1 - 2/15/63 - 63 - 3117

which is UNbalanced on *any* geometry.

A BIOS may (legitimately or not) calculate the size of the partition from the CHS data (try doing it on the spreadsheet) and the result will be a corresponding LBA of 63-2961.

The BIOS now, knowing that the partition is 2961 sectors in size, may access the PBR and check the number of sector written in there (which will be 3117) and since 2961 is different from 3117 could throw an error.

 

I looked at the worksheet, but it is not intuitive to me what values I should put in there myself and what once should be calculated automatically. About the value's I should put in there myself: how should I determine those? Preferably I'd use windows 7/xp compatible software while running these systems (if possible). I guess I could use your MBRviewer script for tiny hexer to help me write the worksheet values onto the bootsectors?
 

There are several sheets in the spreadsheet.

In that version V2 the "main" sheet is the one called "PTtables".

In it you can:

  1. define the geometry of the device in cells F4:H4
  2. define MBR+hidden sectors (as CHS only. but the "orthodox" partiioning has alway 0/0/1-0/0/S where S in the number of sectors in H4)
  3. input some data in either of the three available modes CHS->LBA, LBA->CHS, Numsec->CHS

For the reason stated, unless you define a CHS geometry first, the sheet will calculate "wrong" data.

 

Once you are satisfied with the result, you can (manually) write the values in the PT_to_MBR sheet and obtain the resulting "look" (and hex values) those data will have in an actual hex editor.

The other way round, you can write the hex values of a MBR you have opened with tinyhexer or other hex editor in the MBR_to_PT sheet and obtain a "readable" partition table (same that you would get using directly PTView with tinyhexer).

 

:cheers:

Wonko



#24 Fiction

Fiction

    Member

  • Members
  • 70 posts
  • Location:The Netherlands
  • Interests:Everything IT related, Physics, Mathematics, Fantasy, sci-fi
  •  
    Netherlands

Posted 04 February 2013 - 08:07 PM

Ok, I hope you still check this treat from time to time :P

 

I am trying to 'balance' a 4GB (NOT GiB!) flashdrive. So the first thing I'll need to know is how many sectors per head and heads per cylinder I am dealing with. Is this a BIOS specific thing, or is this writen in the sector 0 somewhere?



#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 February 2013 - 08:23 PM

Ok, I hope you still check this treat from time to time :P
 
I am trying to 'balance' a 4GB (NOT GiB!) flashdrive. So the first thing I'll need to know is how many sectors per head and heads per cylinder I am dealing with. Is this a BIOS specific thing, or is this writen in the sector 0 somewhere?

No, first thing that you need to know is device capacity, EXACT one, in bytes (or sectors).


The most reliable (in my perverted mind) way to do this is detailed here:

http://reboot.pro/to...-alpha/?p=38197

 

just run dsfo redirecting to nul and jolt down the size in bytes.

 

RMPREPUSB should have provisions to test (or just compute) size correctly, BTW.

 

Then you can use the 255/63 HS geometry allright.

 

:cheers:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users