58 replies to this topic

[steve6375]

To repro

1. Use RMPrepUSB to format a USB stick as FAT16 or FAT32, HDD - MS-DOS OS
2. Copy over DOS 7 IO.SYS and COMMAND.COM
3. Check it boots OK (in Qemu)
4. Now install grub4dos to MBR using RMPrepUSB Install grub4dos button
5. Check it boots OK (in Qemu) to grub4dos command line when you type chainloader /io.sys
6. Now repeat steps 1-5, but this time install to PBR --> DOS cannot load COMMAND.COM

If using FAT32 then the last 32 bytes of the PBR seems to be corrupted (with a file entry?? text ?? 'BOOTLOG.TXT')
Note that the PBR does not seem to be corrupted before you boot from the USB stick, only after it tries to boot to DOS.
If FAT16, I cannot see any PBR corruption but still get the error - no command interpreter found.

Would be good if someone could repro without using RMPrepUSB to partition and format and install grub4dos???

[tinybit]

A few questions:
1. Have you tried bootlace.com or other tools, or doing it mannually?
2. The installed PBR's grub4dos version, is it newish(I mean bug free)?
3. Have you tried FreeDOS kernel.sys, instead of IO.SYS?

To clarify, DOS 6.22 IO.SYS has not yet supported by grub4dos' chainloader. By far, for MS-DOS family, only MS-DOS 7 and later can be chainloaded.

The leading 3 bytes of the PBR should be EB xx 90. Please check it. The "90" is a must for (some or all) MS-DOSes, or else the filesystem would not be recognised by DOS and thus "COMMAND.COM not found". The "90" is not mandatory for FreeDOS.

[steve6375]

See https://code.google....ues/detail?id=8

I think FreeDos is not affected, but I need to check all configurations (FAT32/16, 32spt,63spt, etc).

[tinybit]

01E0 42 4F 4F 54 4C 4F 47 20 - 54 58 54 22 00 00 00 00 BOOTLOG TXT"....
01F0 00 00 81 3D 00 00 FD A0 - 81 3D 00 00 00 00 00 00 ..=..ý =......

Obviously, this is a directory entry for file bootlog.txt. It should have been written by DOS.

When DOS boot failed, it might want to write error messages to a file called bootlog.txt.

So it created the file bootlog.txt and wrote messages to it.

And so, not only a directory entry will be written, but also the content of bootlog.txt will be written to some sector regions.

Since DOS might have recognised the wrong geometry, it wrote everything wrongly. Some sectors were corrupted.

This issue proved that at boot time, writing to disk is not a good idea.

-----------

EDIT:

To avoid this problem, you may try to run geometry --tune --sync for this drive, before booting to IO.SYS.

[steve6375]

This issue proved that at boot time, writing to disk is not a good idea.

Yes, but no problem if grub4dos installed to MBR. So installing to PBR causes this issue...

[tinybit]

You might have changed the geometry(i.e., number of heads and sectors per track) of the BPB when writing the PBR.

Before booting to IO.SYS, you may check the geometry of the drive by "geometry (hd0)", and run geometry --tune --sync (hd0) if needed.

[Wonko the Sane]

@steve6375
Please also state the EXACT grub4dos version(s) you tested.

Last time I checked (something like 0.4.3) , grub4dos COULD NOT boot DOS 6.22 by chainloading it's IO.SYS, that was ONLY possible from 7.0 onwards.

MS-DOS 6.22 NEEDS to have IO.SYS as FIRST file in the FAT table (I am pretty sure you already know this ).

In case BOOTPART:
http://www.winimage.com/bootpart.htm
can move the IO.SYS file to the right place, besides creating a compatible bootsector, that you should be able to chainload from grub4dos allright.

Also MS-DOS 6.22 *needs* MSDOS.SYS.


Wonko

[steve6375]

@steve6375
Please also state the EXACT grub4dos version(s) you tested.


Wonko

Sorry it is version 4.10.2222 not 6.22!!! My mistake!!! File time ended with 22 so I thought 'dos 6.22!!'
Only files are io.sys and command.com

It boots fine without grub4dos
It boots fine with grub4dos installed as MBR

0.4.3 used and 0.4.5b latest build.

[steve6375]

You might have changed the geometry(i.e., number of heads and sectors per track) of the BPB when writing the PBR.

Before booting to IO.SYS, you may check the geometry of the drive by "geometry (hd0)", and run geometry --tune --sync (hd0) if needed.

PBR contents both before and after is listed in bug report.

I tried when installed grub4dos to MBR and PBR and after running DOS and getting corruption (complete repartition/format each time) - 30MB ptn 4GB drive

grub4dos as MBR
C/H/S=488/255/63, sector count/size=7839720/512
same after running geometry --tune --sync (hd0)

grub4dos as PBR
C/H/S=488/255/63, sector count/size=7839720/512
same after running geometry --tune --sync (hd0)

grub4dos as PBR after DOS boot (fail command.com)
C/H/S=488/255/63, sector count/size=7839720/512
same after running geometry --tune --sync (hd0)



using --tune (both before and after booting to MSDOS) did not fix anything.

[tinybit]

Thanks. That proves it is not a geometry issue.

emmm....

Try another step. map --mem the drive to memory, and do the above test and see what happens.

[steve6375]

Thanks. That proves it is not a geometry issue.

emmm....

Try another step. map --mem the drive to memory, and do the above test and see what happens.

OK, I made an image of the 30Mb whole partition before I allowed it to boot to MSDOS. Then put that on a flash drive with grub4dos and mapped the file to (rd)
Then mapped (hd0,0) to rd using --mem
ls / shows contents of the 30MB image and not the 30Mb.img file
Then chainloaded (hd0,0)+1

Same result - can't find command.com.

[tinybit]

ok, compress and upload your 30M img please, for me to download and test.

[steve6375]

ok, compress and upload your 30M img please, for me to download and test.

Please see bug report. It has file payload for you to create a USB stick - see DOS.ZIP

https://code.google....all/issues/list

1. Download RMPrepUSB (see my sig for download link)
2. Set RMPrepUSB as:
1 MAX
2 label=MSDOS
3 MSDOS
4 HDD (or all unticked) + FAT32 or FAT16
5 Copy files (from files downloaded from bug report)
6 Prepare Drive button
7 Click on install grub4dos and choose NO to MBR Q so you get PBR install, say Yes to copy grldr

Boot it in Qemu or for real.

[tinybit]

Sorry, I just have no time to complete so many steps.

Could you build a minimal DOS image to reproduce the problem?

Since the boot process of IO.SYS failed, you can build a very small system for concept-proof of the issue.

As you described, mapping the image to memory also can reproduce the problem, so I will do it this way and try to find out why.

[steve6375]

see http://sites.google....b-beta-versions MSDOSGRUBFAT32.ZIP

It is FAT32 image. The PBR sector 63 is not corrupt, but as soon as you boot to MSDOS it is corrupt

I did not put up FAT16 smaller image, as the PBR does not seem to be corrupt when this boots, but it still says COMMAND.COM not found.

[tinybit]

Thanks.

Here is my initial test info:

I build my normal DOS img, lets call it dos_C.img. it is of 4.10.2222(Win98SE).

rename your MSDOSGRUBFAT32.img to dos_D.img.

Run qemu:

qemu -hda dos_C.img -hdb dos_D.img

Now we are under DOS.

dir D:

File not found.

So drive D was not recognized by DOS.

Run debug to do further test, using INT 21,44,D / IOCTL,D - Generic I/O for Block Devices

mov bx,4 ; 0=default drive, 1=drive A, 2=drive B, 3=drive C, 4=drive D
mov ch,8; 8=block device
mov cl, 60h ; get device parameters
mov dx, 200h ; buffer at DS:0200
mov ax, 440dh ; IOCTL
int 21h ; call DOS
int 3 ; break point, stop here.

After running, DS:0200 contains these values(deviceparams structure):

SpecFunc			 db		00	-------- this is wrong. bit 2 should set.

DevType			  db		05	-------- 5=hard drive, this is OK

DevAttr			  dw		0001  -------- bit 0 set for hard drive, this is OK

Cylinders			dw		020E  -------- this is right if Heads=10h.

MediaType			db		00	-------- this is meaningless now. ignore it.

BytesPerSec		  dw		0200  -------- this is OK

SecPerClust		  db		01	-------- this is wrong. it should be 8.

ReservedSectors	  dw		0020  -------- this is wrong. it should be 22h.

FATs				 db		02	-------- this is OK

RootDirEntries	   dw		0200  -------- this is wrong for FAT32

TotalSectors		 dw		0000  -------- this is OK for FAT32

Media				db		F8	-------- this is OK

SectorsPerFAT		dw		100D  -------- this is wrong. it should be 0207

SectorsPerTrack	  dw		003F  -------- this is OK

Heads				dw		0010  -------- this is wrong. it should be FF

HiddenSectors		dd		0000003F ----- this is OK

HugeSectors		  dd		000816A2 ----- this is OK

SectorsPerFAT		dd		0000100D ----- this is wrong. it should be 00000207

According to this initial test, MS-DOS has either a bug or a secret.

[steve6375]

RMPrepUSB applies its own FAT32 tables when it formats, then runs grubinst and the runs touchdrv.exe.

Just to remove RMPrepUSB formatting from the equation, I formatted the partition using Windows 7 format command, then applied grub4dos as follows:

1. Partition USB drive as 300MB FAT32 MSDOS using RMPREPUSB
2. Open Win7 64-bit command line shell as Administrator (USB drive is now drive H:)
3. format h: /q
4. copy grldr, command.com, io.sys to h:
5. run DISKPART and REMOVE H: to dismount volume
6. run grubinst --install-partition=0 (hd1)
7. run diskpart and use ASSIGN command to auto-assign letter to drive again and mount it
8. Boot USB drive using Qemu, type chainloader /io.sys then boot

Result is same as before - COMMAND.COM cannot be found

either grubinst is corrupting something or Windows is corrupting something after grubinst has been run.
The problem does not happen if I install grubinst to MBR.

P.S. If step 7 omitted, I still get same result.

[karyonix]

Before chainloader, please try

grub> debug 2

grub> geometry --tune (hd0)

What messages appear ?

[tinybit]

@karyonix

--tune has a bug, as you had found, and it cannot function well. Looking forward to your fix, karyonix.

@all

Just find out an interesting thing:

Use this

00007E00 EB 58 90 47 52 4C 44 52 35 2E 31 00 02 08 22 00 .X.GRLDR5.1...".

instead of this

00007E00 EB 58 90 47 52 4C 44 52 20 20 20 00 02 08 22 00 .X.GRLDR ...".

and it succeeded!!!!!!

Also succeeded combinations:

GRLDR4.0
GRLDR4.1
GRLDR3.9
GRLDR3.0

And "GRLDR" can be replaced with MSDOS or MSWIN, or even 5 spaces. I guess it can be replaced with any string. But the 3 bytes immediately follows GRLDR cannot be all spaces.

I also tested, if we change the "MSDOS5.1" to bad strings, the MS boot record also failed!!

According to tests so far, it seems:

1. good strings will work for both MS boot record and grub4dos boot record.

2. bad strings will fail for both MS boot record and grub4dos boot record.

So I am almost certain that IO.SYS has a bug.

[Wonko the Sane]

And "GRLDR" can be replaced with MSDOS or MSWIN, or even 5 spaces. I guess it can be replaced with any string. But the 3 bytes immediately follows GRLDR cannot be all spaces.

This may be of interest :
http://homepages.tes...name-field.html
(incomplete table, missing the DOS 7.x/8 and NT based behaviour, but knowing how MS like to re-use code, I assume the above to be a good "hint")


Wonko

[tinybit]

Good page! Thank you very much, Wonko!

[steve6375]

Confirmed , after running grubinst I changed locations in BPB @8,9,10 to "5.1" and no error!

Could a temporary fix be to put a patch into the menu.lst to overwrite these 3 bytes?

[Wonko the Sane]

Good page! Thank you very much, Wonko!

You are welcome.
Also, and possibly UNrelated, the "filling" character may be needed as 00 (as opposed to 20) or at least this is what happens in the known NT/cmdcons hack:
http://www.boot-land...?...c=2362&st=7

And yes, I am unfortunately old enough to remember the havoc created on floppies by the stoopid volume tracker of win 9x, before they came out with the Registry key:
http://support.micro...kb/148637/en-us
which was anyway just a workaround.


Wonko

[tinybit]

Could a temporary fix be to put a patch into the menu.lst to overwrite these 3 bytes?

The OEM string is not used by the boot record of grub4dos. "MSWIN4.1" and "MSDOS5.1"... all works well.

So any tool can change it on the fly.

Next, when we release new grub4dos versions, we should choose a good string, e.g., "MSWIN4.1"

EDIT:

Only one exception: our ext2 boot sector has used oem string for disk I/O error message. So don't write onto the ext2 oem string.

[tinybit]

@Wonko the Sane

I tested GRLDR followed by 3 NULLs, the result is the same as 3 spaces, failed.