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

@steve

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

That would indeed explain a lot.

We need to interrogate the BIOS geometry call (AH=8).

Yeah, I'm not yet much of a assembly hero. I don't know what you mean by AH=8 in this context, but perhaps I forgot something that was already explained. I must admit, I do not understand all of your FAT32 BIOS list. Bit if I understand correctly, the geometry used by the bios get's loaded into the registers at some point in the boot up process. So I should find a MBR code that displays these registers.

 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

    /grub int=0x13 edx=0x80 eax=0x0800
    and see what is returned in ECX and EDX.

I'll try all of these methods and see if they are consistent. I did already run MBR-SPY.

I understand the (unmodified) MBR-SPY MBR code returns registry values when they contain the correct values? It returned:

CS=0000
DS=0000
ES=0000
SS=0000

AX=F000
BX=7C00
CX=0001
DX=0080

BP=1000
SP=03F6
IP=7C00

SI=0005
DI=0000
FG=0246

AX=f000
DX=0080

If so, how should I calculate the geometry from this

With MBR-SPY you need to keep pressing Enter - you should get about 5 sets of results -...

Might be best to take a photo...

Ok, then perhaps this isn't the easiest tool. I'll try the grub method first then.

The first set of results you posted shows the number of sectors per track returned in CX = 1 !!!!

Unfortunately, MBR-SPY does not return the number of heads or cylinders - the author seems to deliberately destroy DH and most of CX!!!

Which is why I recommend my TESTMBR code...

ok i did it and copy these lines

title Stage 1 - XP install\nThis runs the first stage text mode setup

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

 

title Stage 2 - XP install\nChoose the 2nd stage 2 GUI option

chainloader /ntldr

 

now i try to boot again and start winsetup first stage

it boot and loding files but after loading at end it says starting windows setup ( the step b4 format and chose drive ) then i got error after setup is starting windows with error indecates that ( windows must creat \windows folder in order to install windows ) and i have 2 options down ( enter = retry F3 = quit )

 

So what system are you booting it on and does it have a working internal hard drive in IDE mode?

Ok, I thought I could install the grub4dos bios utility by just copying the bios file to the drive, but when I type /grub followed by whatever, it returns: 'warning! no such command: /grub'

I tried the TESTMBR, MBR1P63S would not boot,
MBR1P32S returned:

80
0000 7F03 003F 032B
LHDD0 00
SHDD0 00

If I understand correctly from http://www.rmprepusb...s/diagnose-bios

The 7F is the number of heads: 128
03 is the number of disks detected. This is correct as there are 2 internal harddisks (perhaps I should have mentioned this)

003F so 63 sectors per track
032B 812 cylinders?

Does this mean a 812/128/63 geometry?

So I might be dealing with a rare 128/63 bios!

This does not matter for the internal disk, because it is to large to be accesed by CHS anyway and the bios swiches to LBA in this case, right?

*edit*

@steve

Could you explain to me why the first file would not boot? I have a feeling it should be obvious now, but it somehow isn't to me.

Edited by Fiction, 09 February 2013 - 10:39 PM.

Yes, looks like a weird 128 heads per cylinder!

No idea why the MBR1P63 did not work!

re '/grub', try typing the name of the file that you copied in order to run it - e.g. /bios  (or it it had an extension type the full name - e.g. /bios.g4e)

Tried that /bios would not work either.

Is the bios file the only one that should be copied to the flashdrive (aside from grldr) or should I copy some other files over? Does it matter that the grub4does was installed in the MBR, not the PBR?

*edit*

I looked at the MBR1P63 file. Tiny hexer (MBR view) tells me the partition start sector is 0/0/1 lba 63. But is 0/0/1 not LBA 0?

Does this mean the MBR1P63 files is unblanced, even for 255/63, or is there a reason for picking these values? I would expect to see 0/1/1 not 0/0/1

*edit*

I changed the 0/0/1 to 0/1/1 using tiny hexer. Now the MBR1P63 version boots fine. It returns exactly the same thing as the MBR1P32 did.

Doest this mean my version of MBR1P63 is corrupt, or is the version currently shipped with the RMPrepUSB unbalanced?

Edited by Fiction, 09 February 2013 - 11:27 PM.

try 

ls /bios

if that doesn't list the file, then try

ls /

if you copied the file 'bios' to the root of the boot drive, then /bios should work (as long as you also typed in the other bits of the line of course!), i.e.

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

doh!  just noticed my mistake! I said /grub when I should have said /bios   !!!! Sorry!!!!

P.S. as the BIOS expects 7F for the no. hds, if you hexedit the BPB (sec 63) offset 1ah to 007F then it might get a bit further.

I am sorry, the page did not refresh correctly, so I edited my previous post instead of posting a new one.

Let me quote myself, so make the discussion easier for you:

*edit*

I looked at the MBR1P63 file. Tiny hexer (MBR view) tells me the partition start sector is 0/0/1 lba 63. But is 0/0/1 not LBA 0?

Does this mean the MBR1P63 files is unblanced, even for 255/63, or is there a reason for picking these values? I would expect to see 0/1/1 not 0/0/1

*edit*

I changed the 0/0/1 to 0/1/1 using tiny hexer. Now the MBR1P63 version boots fine. It returns exactly the same thing as the MBR1P32 did.

Doest this mean my version of MBR1P63 is corrupt, or is the version currently shipped with the RMPrepUSB unbalanced?

Does the partition on your version of MBR1P63 start at 0/0/1 or at 0/1/1? Could you verify this?

I'll try booting a 128 balanced grub drive tomorrow. The /bios command would not work as it is now (255 balanced in stead of 128). But ls did find the file, weird enough.

Just checked the source asm and it does say 0,0,1 for some of them which is wrong (unbalanced)! Not sure how that happened! I will fix it tomorrow!

However, it should not affect whether or not the TESTMBR boots. All the code is in the MBR. The PBR is never loaded by my code.

So the actual values of the start CHS of the partition table should be irrelevant and make no difference to whether the MBR code runs or not!

So it is very interesting that you say that the MBR1P63S does not run, but that it does when you patch the start head number to be 1 instead of 0!

That should not make any difference!

The BIOS should just load the MBR and run it. What error did it give (if any) with MBR1P63S or did it just hang or what?

It told me there was no boot-able disk...

*edit*

However, 0/0/1 points to the MBR does it not? Perhaps the bios thought sector 0 was the first partition sector and therefore thought there was no MBR code? I must admit, it is odd. Why read the geometry before the MBR bootcode?

Would there be an easy way to test this behaviour? (What a weird bios!)

Edited by Fiction, 10 February 2013 - 01:09 AM.

since the bios uses 812 cylinders and 128 head, I seem limited to 6547905 sectors in thirst partition in order for it to be balanced. This is a 3.12 GiB limit for the 1st parition isn't it? Then why does the bios swich to chs at all for the 3.7 GiB partition earlier, if the volume clearly exceeds the bios's chs capability?

Try setting hd0 sec2

Where should I do that, grub4dos?

Use disk editor to edit the first sector of the disk.

Install MBR1P63S

Run RMPrepUSB

Seelct USB drive and Press CTRL-D

Set Start=0  No Sectors=1

Click Sequential Read

Click Display and Edit Buffer

Change text that is displayed

Click on Write Using Buffer

Exit

It is not the BIOS switching to CHS, it is the code in the PBR.

Code can access the disk via Int 13h calls to the BIOS.

The BIOS had the old method which uses AH=2 and you put the CHS values in the registers before you make the call. This had an 8GB limitation.

Later the BIOS spec, added AH=42h which took LBA values instead of CHS values.

So now there are two ways to read/write sectors, AH=2 or AH=42h.

The code in the PBR loads the start position of the 2nd stage of the FAT32 boot code (at sector PBR(63)+12).

If that position is over the 128x63x812 position then the code in the PBR chooses to use EBIOS (LBA) calls to the BIOS, if the position is less than 128x63x812 (which it is), then the code in the PBR calls the old CHS BIOS interface and converts the LBA address to CHS using the parameters in the PBR BPB table (i.e. using 255x63). That code loaded at 63+12 searches the filesystem for the ntldr file - but has problems (probably tries to access head 129 (as it thinks there are 255 heads) and the BIOS rejects the command as having an illegal head value)?

Interesting, it seems like the xp boot code does not care that much about the actual geometry listed in the MBR. I left those values 'wrong' namely 254 etc, aka 255/63 balanced.

I only changed the BPB value for the heads to 128, same for the bootsect.dat. Now the xp install drive boots like a charm... Perhaps it just notices that the values in the mbr are higher then the max values based on 128 heads and it resides on using LBA?

Or...

It is not the BIOS switching to CHS, it is the code in the PBR.

Do you mean by this, that the MBR geometry values are ignored, when determining whether or not to use CHS?

Does the XP boot code only read the number of heads in the BPB and reside to use CHS accordingly? This would indeed explain why I would not boot before, the bios got a number of heads bigger then 128 and did know where to look for the ntldr. So this does not actually seem like a balancing issue. Apparently the bios boots fine onto the drive despite the geometry as described in the MBR seems 'weird' to it. I guess the bios just thought: 'dont understand, let's use LBA'. It probbably was only the xp boot code that thought it was a good idea to look for the NTDLR using 255 heads chs. This way, none of them check whether or not the entire partition is equally large using chs/lba. I'll test if this is true, by changing the MBR CHS values to make them no longer 255/63 balanced (but ill still use more than 128 heads, in order for the bios to switch to lba).

After this test I'll try the things you suggested.

*edit*

Ok, so as long as 128 heads are suggested by the BPB, this partition table boots fine:

While the CHS end values are clearly messed up (even the starting sector!). However, because the values seem 'weird' to the 128 heads bios, it happily switches to LBA. Microsoft should try this as well, switching to LBA when CHS fails

*edit2*

Now I am curious... would the bios be smart enough to switch to lba if the number of heads stays below 128, but the start and end sector CHS are completely wrong. I'll test one more time, with eHead=120

*edit3*

It actually is that smart

It did boot the 120 eheads drive just fine. I am starting to suspect it will always use LBA if it is supported by the MBR. Wich makes it even weirder that it would care about the MBR1P63S chs start sector =/

Why check CHS before deciding to boot the MBR when you run LBA anyway?

*edit4*

Use disk editor to edit the first sector of the disk.

    Install MBR1P63S

    Run RMPrepUSB

    Seelct USB drive and Press CTRL-D

    Set Start=0  No Sectors=1

    Click Sequential Read

    Click Display and Edit Buffer

    Change text that is displayed

    01B0 07 B4 0E CD 10 C3 00 00 - 00 00 00 00 00 00 80 00  .´ÍÃ.. ......€.
    01C0 01 00 0B FE 7F EE 3F 00 - 00 00 F0 56 79 00 00 00  ...þî?. ..ðVy...
    change to
    01B0 07 B4 0E CD 10 C3 00 00 - 00 00 00 00 00 00 80 00  .´ÍÃ.. ......€.
    01C0 02 00 0B FE 7F EE 3F 00 - 00 00 F0 56 79 00 00 00  ...þî?. ..ðVy...

    Click on Write Using Buffer

    Exit

I did this. It boots fine and displays the same results as seen before (128 heads, 812 cylinders).

What does this flip from 01 to 02 imply?

Edited by Fiction, 10 February 2013 - 11:50 AM.

Ok, I seem to be disallowed any more edits to the previous post

Anyway, I noticed, using tiny hexer, what this byte does. It is the start sector number. So changing it from 0/0/1 to 0/0/2 makes it instantly boot-able. This seems to agree with my suggestion that the bios notices the partition starts at the MBR sector and thinks 'there is no way this drive actually contains a bootable parition'. Still wondering why it would use CHS for this.

However, before we agree this is a correct conclusion: the 0/0/1 variant start working for some reason. Eh, what? The only think I can think of that I changed was that I disallowed the bios from booting onto the internal harddisk (I disabled booting from disk0 in the bios).

I'll test a few thinks to see if I can reproduce this.

A different suggestion is that I was sloppy creating the MBR. The first few times I used tinyhexer for the job. I started using the RMPrepUSB file>drive function for the more recent few...

It must regard 0/0/1 as an invalid start sector I suppose?

Before you do any tests - use RMPrepUSB CLEAN to ensure no old PBR is around.

Not sure if you read my last post?

It seems like the bios settings do have something to matter with this. Setting disk0 as a secondary boot device makes it completely ignore the MBR1P63S and boot straight into the disk0. Perhaps I did confuse this behaviour with the 'no disk found' error. I most cases. Ignoring a drive and displaying this message is the same thing.

I'll test some more. I'll do more then just a single test before editing again. Otherwise my edit button might vanish again

Make sure you switch off the test PC each time. Some BIOSes remember the device format if you just warm reboot - so ALWAYS switch off every time you change the USB contents.