Strange MS-DOS bug when installing grub4dos to PBR
#1
Posted 01 December 2010 - 11:20 PM
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???
#2
Posted 02 December 2010 - 01:14 AM
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.
#3
Posted 02 December 2010 - 08:00 AM
I think FreeDos is not affected, but I need to check all configurations (FAT32/16, 32spt,63spt, etc).
#4
Posted 02 December 2010 - 09:09 AM
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.
#5
Posted 02 December 2010 - 09:12 AM
Yes, but no problem if grub4dos installed to MBR. So installing to PBR causes this issue...This issue proved that at boot time, writing to disk is not a good idea.
#6
Posted 02 December 2010 - 09:35 AM
Before booting to IO.SYS, you may check the geometry of the drive by "geometry (hd0)", and run geometry --tune --sync (hd0) if needed.
#7
Posted 02 December 2010 - 09:36 AM
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
#8
Posted 02 December 2010 - 11:08 AM
@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.
#9
Posted 02 December 2010 - 12:00 PM
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.
#10
Posted 02 December 2010 - 01:35 PM
emmm....
Try another step. map --mem the drive to memory, and do the above test and see what happens.
#11
Posted 02 December 2010 - 11:20 PM
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)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.
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.
#12
Posted 03 December 2010 - 12:54 AM
#13
Posted 03 December 2010 - 08:02 AM
Please see bug report. It has file payload for you to create a USB stick - see DOS.ZIPok, compress and upload your 30M img please, for me to download and test.
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.
#14
Posted 03 December 2010 - 08:49 AM
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.
#15
Posted 03 December 2010 - 11:19 AM
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.
#16
Posted 04 December 2010 - 02:47 AM
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.
#17
Posted 04 December 2010 - 10:17 AM
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.
#18
Posted 04 December 2010 - 11:17 AM
grub> debug 2 grub> geometry --tune (hd0)What messages appear ?
#19
Posted 04 December 2010 - 12:12 PM
--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.
#20
Posted 04 December 2010 - 12:22 PM
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
#21
Posted 04 December 2010 - 12:39 PM
#22
Posted 04 December 2010 - 01:03 PM
Could a temporary fix be to put a patch into the menu.lst to overwrite these 3 bytes?
#23
Posted 04 December 2010 - 01:13 PM
You are welcome.Good page! Thank you very much, Wonko!
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
#24
Posted 04 December 2010 - 01:38 PM
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.
#25
Posted 04 December 2010 - 01:53 PM
I tested GRLDR followed by 3 NULLs, the result is the same as 3 spaces, failed.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users