71 replies to this topic

[wiesl]

Good , then post just the MBR and the PBR, with those I can re-build an image and make a few tests.
Sorry but I cannot make head or tail of your last post.
If you want help in troubleshooting the issue, please provide what I asked for, so that I can do a few tests.

Ok, clarification:
I recorded sector reads to track down the problem. Left side records the working BOOTSECT.620 loading from NTLDR. Right side records the NON working loading of IO.SYS from GRUB4DOS.
Both records are done from the time pressing ENTER in either NTLDR or GRUB4DOS.

Afterwards I made a comparision (diff) of both. Left side is the working side, right side the non working side.

Letters in the middle mean:
| difference
< or >: not here

The relevant findings are:

Last sector of this read is ROOT DIR entry: scsi-disk: Read (sector 504, count 63)

Read inside command.com: scsi-disk: Read (sector 2931390, count 63)

Read second ROOT DIR entry: scsi-disk: Read (sector 567, count 63)

Inside IO.SYS: scsi-disk: Read (sector 2931453, count 63)

Garbage: scsi-disk: Read (sector 189, count 63)

Garbage: scsi-disk: Read (sector 242, count 1)

Start of IO.SYS: scsi-disk: Read (sector 2931414, count 39)

Inside IO.SYS: scsi-disk: Read (sector 2931453, count 63)

Inside IO.SYS: scsi-disk: Read (sector 2931478, count 38)

Garbage, partly MSDOS.SYS: scsi-disk: Read (sector 2931516, count 26)

Garbage: scsi-disk: Read (sector 3168342, count 54)

scsi-disk: Read (sector 3168396, count 10)

Garbage, some FAT DIR entries: scsi-disk: Read (sector 3168396, count 10)

Left side reads MSDOS.SYS correctly, GRUB4DOS not:

scsi-disk: Read (sector 242, count 1)											| scsi-disk: Read (sector 257, count 1)

scsi-disk: Read (sector 2931542, count 37)									  | scsi-disk: Read (sector 3168342, count 54)

scsi-disk: Read (sector 2931579, count 63)									  | scsi-disk: Read (sector 3168396, count 10)

scsi-disk: Read (sector 2931642, count 28)									  <

I think I have to look at the code to understand what happens. Maybe someone can tell the general read strategy for IO.SYS.

Thanx.

Wiesl

[Wonko the Sane]

FAT16 ptn has 2GB limit so should be OK.

Yep, my bad somehow (I am getting old ) an entire sentence remained in my pen keyboard
Added to my previous post, corrected, sorry.

@wiesl
I'll try a few things and let you know.

How EXACTLY was the device partitioned/formatted?
It uses a "wrong" number of heads: 196 that does not correspond to *any* head geometry known to mankind.
The disk image being around 6 Gb the Qemu BIOS will expose a device geometry of 255 heads, and as thus your partitions are not on a cylinder boundary.
I will try to rebuild, but that is the main suspect right now.

EDIT:
rebuilt the disk/volume.
The thingy boots allright in Qemu with "plain":

root (hd0,0)

chainloader /io.sys

boot

with the English version of MS-DOS 6.22 files.
So, it seems like the issue is with the German DOS files
(still the "strange" head number may cause other problems)
Can you try with the English version on your setup?
Are you using 6.20 or 6.22 (there may be other differences)

EDIT:
No, it is not even the German version , I just tested with German files:
IO.SYS 41.055 bytes MD5: B6F035286ACD3CF778A239796CBDF5E6
MSDOS.SYS 38.186 bytes MD5: D4C76B63F608A9A282F99F53D5625400
COMMAND.COM 57.377 MD5: 8943FC863B7FEA99ED6D50B0A2EC318F

MD5 calculated with:
http://wayback.archi...ilities/md5.zip

My tests are made booting from a grub4dos floppy. I tried both grldr and grub.exe. Maybe the difference is with the grub4dos loaded through NTLDR+BOOT.INI?



EDIT:
just tested booting to hard disk using NTLDR+BOOT.INI (SP6a English) to load grldr and all works normally.


Wonko

[wiesl]

@wiesl

How EXACTLY was the device partitioned/formatted: Long time ago on an NCR/Symbios Logic/LSI 53C875A SCSI physical system. Currently I'm using it on an VM with QEMU with LSI 53C895A SCSI disks. Therefore the translation is different and default LSI logic one.

Can you try with the English version on your setup? Not easily possible.
Are you using 6.20 or 6.22 (there may be other differences): 6.22 German

MD5sum generated under Linux, filesizes are the same, but MD5s are DIFFERENT!!!!

8943fc863b7fea99ed6d50b0a2ec318f  COMMAND.COM

325bc99303a306c5d9798762a5e64c62  IO.SYS

d4c76b63f608a9a282f99f53d5625400  MSDOS.SYS

b5f777672f276b7e60ea90893cf5f79e  NTLDR

e3bd4a2dda356a78d9904ab2b9731b5e  NTLDRXP

Strange. Maybe it is because of SCSI.

Did you find something in MBR/VBR?
How did you setup NTLDR so quickly?
Any further ideas?

Thank you.

Wiesl

[Wonko the Sane]

Strange. Maybe it is because of SCSI.

It is possible.
Do a dd copy of the disk to an image and use the RAW image in Qemu (default, using virtual IDE) to see what happens

Did you find something in MBR/VBR?

As said geometry is - to say the least - "queer", but seemingly did not prevent the experiment here.

How did you setup NTLDR so quickly?

What do you mean quickly?
you already provided the VBR, I just got the NT4.00 SP6a, and got from it NTLDR and NTDETECT.COM (though the latter is obviously not used) and wrote a BOOT.INI.

The MD5 is different only for IO.SYS, which makes sense since the date was changed also.
I got those files from an old backup, cannot really say where the boot disk image came from,



Wonko

[roytam1]

Yep, my bad somehow (I am getting old ) an entire sentence remained in my pen keyboard
Added to my previous post, corrected, sorry.

@wiesl
I'll try a few things and let you know.

How EXACTLY was the device partitioned/formatted?
It uses a "wrong" number of heads: 196 that does not correspond to *any* head geometry known to mankind.
The disk image being around 6 Gb the Qemu BIOS will expose a device geometry of 255 heads, and as thus your partitions are not on a cylinder boundary.
I will try to rebuild, but that is the main suspect right now.

EDIT:
rebuilt the disk/volume.
The thingy boots allright in Qemu with "plain":

root (hd0,0)

chainloader /io.sys

boot

with the English version of MS-DOS 6.22 files.
So, it seems like the issue is with the German DOS files
(still the "strange" head number may cause other problems)
Can you try with the English version on your setup?
Are you using 6.20 or 6.22 (there may be other differences)

EDIT:
No, it is not even the German version , I just tested with German files:
IO.SYS 41.055 bytes MD5: B6F035286ACD3CF778A239796CBDF5E6
MSDOS.SYS 38.186 bytes MD5: D4C76B63F608A9A282F99F53D5625400
COMMAND.COM 57.377 MD5: 8943FC863B7FEA99ED6D50B0A2EC318F

MD5 calculated with:
http://wayback.archi...ilities/md5.zip

My tests are made booting from a grub4dos floppy. I tried both grldr and grub.exe. Maybe the difference is with the grub4dos loaded through NTLDR+BOOT.INI?



EDIT:
just tested booting to hard disk using NTLDR+BOOT.INI (SP6a English) to load grldr and all works normally.


Wonko

German version of MS-DOS 6.2 works here.


Please make a screen dump after running chainloader /io.sys and then run "cat --hex (md)2+1", you should have a shot like this:

in 0x100 shows the dir-entry of IO.SYS and MSDOS.SYS, which is required for loading MS-DOS 6.x correctly.

[wiesl]

German version of MS-DOS 6.2 works here.

Please make a screen dump after running chainloader /io.sys and then run "cat --hex (md)2+1", you should have a shot like this:
in 0x100 shows the dir-entry of IO.SYS and MSDOS.SYS, which is required for loading MS-DOS 6.x correctly.

OK, looks like that MSDOS.SYS isn't on the second location in DIR entry.

I think we are further!

Regarding Syntax: cat --hex (md)2+1
What does (md) mean?
The 2 (offset)?
The +1(length)?
Dokumentation?
(Seems to be blocklist syntax: https://www.gnu.org/...ock-list-syntax)
How to realocate dir entries?
How to get the absolute position of this entry?
Would it be easy to expand code for looking at other positions in root dir entries, too?

I'm also finding: (I think there are 2 root dir entries, right?)

00310a60  69 6f 2e 73 79 73 00 00  00 00 00 00 00 5f a0 00  |io.sys......._..|

00310a70  00 bf 1c c0 32 6d 73 64  6f 73 2e 73 79 73 00 00  |....2msdos.sys..|

00310a80  00 00 2a 95 00 00 bf 1c  c0 32 63 6f 6d 6d 61 6e  |..*......2comman|

00310a90  64 2e 63 6f 6d 00 00 21  e0 00 00 bf 1c c0 32 44  |d.com..!......2D|

Thnx.

Wiesl

Attached Thumbnails

• 

[roytam1]

OK, looks like that MSDOS.SYS isn't on the second location in DIR entry.

I think we are further!

I'm also finding: (I think there are 2 root dir entries, right?)

00310a60  69 6f 2e 73 79 73 00 00  00 00 00 00 00 5f a0 00  |io.sys......._..|

00310a70  00 bf 1c c0 32 6d 73 64  6f 73 2e 73 79 73 00 00  |....2msdos.sys..|

00310a80  00 00 2a 95 00 00 bf 1c  c0 32 63 6f 6d 6d 61 6e  |..*......2comman|

00310a90  64 2e 63 6f 6d 00 00 21  e0 00 00 bf 1c c0 32 44  |d.com..!......2D|

Thnx.

Wiesl

renaming IO.IDX and MSDOS.--- to other name (main filename not "IO" and "MSDOS") will make it able to boot for the time being. I'll try to fix it to ensure the routine copies exact name but not same main filename with different file extension, next build will copy first occurrence entry of each filename)

Regarding Syntax: cat --hex (md)2+1
What does (md) mean?
The 2 (offset)?
The +1(length)?
Dokumentation?
(Seems to be blocklist syntax: https://www.gnu.org/...ock-list-syntax)

(md) means "memory device", which is the real memory(or say, memory) in the running system.
2 is offset, in sector (512 bytes)
+1 us length, in sector (512 bytes)

Yes it is same as blocklist syntax.

How to realocate dir entries?
How to get the absolute position of this entry?
Would it be easy to expand code for looking at other positions in root dir entries, too?

the routine following BPB in Partition Boot Record to find out the starting address of root dir entry, read it to a temporary location (it is 0x400-0x800 in memory) and find and move specified entry to 0x500 and up.
You may need to modify and recompile the source in order to expend its function.

Edited by roytam1, 22 February 2012 - 07:05 AM.

[wiesl]

I'll try to fix it to ensure the routine copies exact name but not same main filename with different file extension)

(md) means "memory device", which is the real memory(or say, memory) in the running system.

Sounds good that you try to fix it. I'm always detecting bugs in my environment :-)

Is it possible to find out where md currently points to?

Thnx.

Wiesl

[roytam1]

Sounds good that you try to fix it. I'm always detecting bugs in my environment :-)

Is it possible to find out where md currently points to?

Thnx.

Wiesl

Please try this build:
http://code.google.c...&q=#makechanges

(md) always points to whole memory area that usable by Grub4DOS.

[wiesl]

Please try this build:
http://code.google.c...&q=#makechanges

(md) always points to whole memory area that usable by Grub4DOS.

Can confirm this build works :-)
Also without --msdos switch. Why?

Points also to correct IO.SYS/MSDOS.SYS.

BTW: Can you explain a little bit the concept of loading IO.SYS/MSDOS.SYS since code is a little bit confusing.

Thnx.

Wiesl

[roytam1]

Can confirm this build works :-)
Also without --msdos switch. Why?

Points also to correct IO.SYS/MSDOS.SYS.

BTW: Can you explain a little bit the concept of loading IO.SYS/MSDOS.SYS since code is a little bit confusing.

Thnx.

Wiesl

MS-DOS 6.x/PC-DOS 7.x are auto-detected, so it will also work without switch.

The original idea is taken from FreeDOS oemboot.asm
http://freedos.svn.s...482&view=markup

Edited by roytam1, 22 February 2012 - 08:36 AM.

[Wonko the Sane]

All is well that ends well.


Wonko

[steve6375]

Strange discovery
If not using grubdos, both 255x63 AND 63x32 Hd/Sector geometry boot fine to DOS 6.22 as FAT16 100MB partition.

However, when grub4dos is installed - if the disk geometry is 255x63 FAT16 Ptn type 06 then this works:

titile MS-DOS

chainloader /io.sys

However, the menu above does NOT work (hangs) if the drive geometry is 63HD/32SEC !!!
but

title MS-DOS

chainloader +1

does work for both FAT 16 255x63 and FAT 16 63x32 - seems to indicate a grub4dos issue?

Using --msdos does not fix the problem. Nor does geometry --tune & --sync.
2012-02-21 chenall build does not fix either. Any ideas?

P.S. Also same for DOS 7 Win98 version!

[wiesl]

What do you mean quickly?
you already provided the VBR, I just got the NT4.00 SP6a, and got from it NTLDR and NTDETECT.COM (though the latter is obviously not used) and wrote a BOOT.INI.

So the steps were?
1.) Make large enough image (e.g ~6GB)
2.) Install MBR at sector 0
3.) Install VBR at sector 63
4.) Formatting with FAT. How?
5.) Copy files
6.) Test
Right?

Can you please clarify.

Thnx.

BTW: I like the activity of the people in this forum :-)

Wiesl

[roytam1]

Strange discovery
If not using grubdos, both 255x63 AND 63x32 Hd/Sector geometry boot fine to DOS 6.22 as FAT16 100MB partition.

However, when grub4dos is installed - if the disk geometry is 255x63 FAT16 Ptn type 06 then this works:

titile MS-DOS

chainloader /io.sys

However, the menu above does NOT work (hangs) if the drive geometry is 63HD/32SEC !!!
but

title MS-DOS

chainloader +1

does work for both FAT 16 255x63 and FAT 16 63x32 - seems to indicate a grub4dos issue?

Using --msdos does not fix the problem. Nor does geometry --tune & --sync.
2012-02-21 chenall build does not fix either. Any ideas?

P.S. Also same for DOS 7 Win98 version!

I can't test as QEMU don't accept H > 16.

[steve6375]

To repro

• Run latest version of RMPrepUSB and set 100MB + FAT16 + 64/32 + MSDOS and click Prepare Drive (use a USB Flash drive)
• Use a disk editor to change partition type byte at 1C2h to 06 (from 0E). You can use DiskDoctor in RMPrepUSB Alt+Ctrl+F5 - read 1 sector - Display - edit listing - Write Buffer.
• Add IO.SYS, MSDOS.SYS and COMMAND.COM DOS 6.22
• Click QEMU button in RMPrepUSB - it should boot fine
• Now install grub4dos using RMPrepUSB Install Grub4dos button
• Edit menu (press F4 in RMPrepUSB ) and try chainloader /io.sys ---> hangs on booting

[wiesl]

I can't test as QEMU don't accept H > 16.

Try SCSI (LSI 53c895a with LSI BIOS). Works well here.

Wiesl

[roytam1]

To repro

• Run latest version of RMPrepUSB and set 100MB + FAT16 + 64/32 + MSDOS and click Prepare Drive (use a USB Flash drive)
• Use a disk editor to change partition type byte at 1C2h to 06 (from 0E). You can use DiskDoctor in RMPrepUSB Alt+Ctrl+F5 - read 1 sector - Display - edit listing - Write Buffer.
• Add IO.SYS, MSDOS.SYS and COMMAND.COM of DOS 7 (or DOS 6.22)
• Click QEMU button in RMPrepUSB - it should boot fine
• Now install grub4dos using RMPrepUSB Install Grub4dos button
• Edit menu (press F4 in RMPrepUSB ) and try chainloader /io.sys ---> hangs on booting

Because the geometry is different.


and likely the BPB doesn't look correct to DOS IO.SYS

If you boot from DOS 6.22 floppy image in QEMU and sys c:
It will boot correctly in grub.exe/grldr

Edited by roytam1, 22 February 2012 - 01:25 PM.

[steve6375]

Yes! This fixes it

title Boot MSDOS 6.22

geometry --bios --sync

chainloader /io.sys

Only needed for QEMU. If boot on real system (Asus 904 EeePC) then chainloader /io.sys works. Presumably some BIOSes look at the partition END Head/Sector values and correct the disk geometry table before booting, but QEMU does not?
So issue is caused by not 'sys'ing under the 'target' BIOS and of course RMPrepUSB does not know what geometry the BIOS will use.

P.S. It seems some of the problem is to do with the QEMU version that recent versions of RMPrepUSB is using. A FAT32 DOS 7 version will not boot using chainloader /io.sys with RMPrepUSB QEMU - but it does boot under QEMU Manager . An older version of QEMU works but more recent ones don't (same BIOS.BIN file).

[Wonko the Sane]

So the steps were?
1.) Make large enough image (e.g ~6GB)
2.) Install MBR at sector 0
3.) Install VBR at sector 63
4.) Formatting with FAT. How?
5.) Copy files
6.) Test
Right?

Almost.
1) "Grow" MBR from 512 to 32256 bytes (using fsz.exe, part of the DSFOK)->MBR.img
2) "Grow" VBR1 to full volume size AND "format" it (using an experimental batch I have put together) ->VBR1.ima
3) COPY /B MBR.img + VBR1.ima
4) "Grow" MBR.img to full size of image (6.442.267.648 bytes) - still using fsz.exe
5) mount image with IMDISK and copy files to it (IO.SYS,MSDOS.SYS, COMMAND.COM)
6) Test in Qemu (+Qemu Manager)

Actually it was a nice "real life" way to test the little batch.
There is still some work to do on it (mostly rounding currently pointed edges and optimizing/speeding it up) but I expect to be able to release it in a few days.
If you are interested in it, it wil be released here:
http://www.msfn.org/...s/page__st__151
(that one is "read only" version 0.05, the one I used is the 0.08 experimental unreleased)

As a teaser , this is a screenshot:


(the screenshot is a lie, option #3 is there and it works )


Wonko

[wiesl]

MS-DOS 6.x/PC-DOS 7.x are auto-detected, so it will also work without switch.

The original idea is taken from FreeDOS oemboot.asm
http://freedos.svn.s...#38;view=markup

OK, had a look at the source code, basically it does:
1.) Identify & calculate pointers to different FAT areas (http://en.wikipedia....on_Table#Layout)
2.) Search for IO.SYS in root directory
3.) When found, get the FAT chain of IO.SYS
4.) Load the sectors into memory
5.) Start it

Quite logically so far like a normal FAT read into memory & execute.

But GRUB4DOS has also code for MSDOS.SYS which is as far as I know loaded from IO.SYS. Why? Any ideas why the code is necessary?

Thnx.

Wiesl

[roytam1]

OK, had a look at the source code, basically it does:
1.) Identify & calculate pointers to different FAT areas (http://en.wikipedia....on_Table#Layout)
2.) Search for IO.SYS in root directory
3.) When found, get the FAT chain of IO.SYS
4.) Load the sectors into memory
5.) Start it

Quite logically so far like a normal FAT read into memory & execute.

But GRUB4DOS has also code for MSDOS.SYS which is as far as I know loaded from IO.SYS. Why? Any ideas why the code is necessary?

Thnx.

Wiesl

MSDOS.SYS is loaded by IO.SYS, which is located from root dir-entry list in 0050:0000.
So Grub4DOS do step 1 and copy IO.SYS and MSDOS.SYS dir-entry to 0050:0000, load IO.SYS in memory and run.

[wiesl]

title Windows NT 4.0 (find and load NTLDR of Windows NT 4.0)
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader --force --load-segment=0x2000 /ntldr
#savedefault --wait=2

BTW:
Is it possible to give directly parameters to NTLDR like in BOOT.INI (like e.g. /sos /basevideo)?
Is it possible to set timeout in Grub4DOS to zero to boot directly?

Intention: I don't want 2 menu selections (GRUB4DOS and then NTLDR) ...

Thanx.

Wiesl

[Wonko the Sane]

Is it possible to give directly parameters to NTLDR like in BOOT.INI (like e.g. /sos /basevideo)?

No, but you can workaround the problem (use a ramdisk or a smallish floppy image and write "on-the-fly" a "single entry" BOOT.INI).
A "NT boot floppy" is what I personally recommend:
http://www.xxcopy.com/xxcopy33.htm


Wonko

[wiesl]

No, but you can workaround the problem (use a ramdisk or a smallish floppy image and write "on-the-fly" a "single entry" BOOT.INI).
A "NT boot floppy" is what I personally recommend:
http://www.xxcopy.com/xxcopy33.htm

Clear so far with static floppy images for different boot options (every line requires one image).
How will it work with "on the fly" option creating BOOT.INI entries?

Can you clarify.

Thnx.

Wiesl