Resurrecting a old post here, since it still happens, and in some circumstances
is REALLY annoying, and can wast a lot of time ...

I have been using FreeDos for more then ten years in combination with
the DOS version of my Partitioning and Filesystem analysis tool 'DFSee'.
(and so have a lot of DFSee customers :)

------------8<--------------- posted Nov 9, 2012, with a reply by Eric Auer:

>> I was going to install FreeDOS 1.1 on a USB drive within qemu 1.1.1 on
>> Opensuse 12.2 32 bit. After selecting the language in the FreeDOS
>> installer, my notebook was busy during the next hour with thousands of
>> thousands of messages like "Run chkdsk: Bad FAT I/O: 0x...".

The kernel produces that message when "getblock" fails. Bernd,
the message is printed by "clusterMessage" and "getblock" is a
macro for "getblk" (x, y, FALSE) which apparently is, more or
less, a wrapper for "dskxfer" to let BUFFERS do their work...

>Probably something tried to access the drive as if it already
>was formatted while it was not, maybe failed to set a flag to
>mark the drive as unformatted in some internal processing...

------------8<--------------- end post Nov 9, 2012:

I have seen this problems numerous times over the last 10 years,
starting with the 1.0 kernel, then the 1.1, and I now just verified that
it still happens with the kernel that is in the 1.2 RC1 release.

Description of the problem symptoms:

On booting FreeDOS, AFTER processing config.sys and at least
after a part of the stuff in AUTOEXEC.BAT, it may happen that 
error messages scroll by, relatively fast, and for a long time:

        Run chkdsk: Bad FAT I/O: 0x00000001

The message is repeated at least a dozen times, then the sector/block number
is incremented and another bunch or errors is repeated.

This can go on for a LONG time, in my test-setup (VirtualBox on SSD) it counts
up to block 0x00000100 in a few minutes, but I have seen reports where it did 
even more and took over half an hour to complete.
(after wich FreeDOS runs normally by the way)

Further analysis and testing showed that this happens IF:

There is a FAT type partition: 0x06, 0x0B, 0x0C, 0x0E, either primary or lgical

The partition is NOT formatted, or more exact, has no '0x55 0xAA' signature
in the last two bytes of the bootsector.

The problem is almost certainly in the KERNEL.SYS, where it does not
test for a valid bootsector before trying to mount the partition as FAT.
It then uses incorrect values for the layout (bps, offsets or other geometry)
and gets I/O errors as a consequence.

The amount of errors reported seems to depend on the size of the partition.
In my case it was just a few minutes, but it could be much more.

I tested the same issue with the newer (May 2016) kernel,
but unfortunately it still has the same issue.

To avoid or work around the problem, either:

FORMAT it directly after creating it (before booting FreeDOS)

Just do a 'fixboot' in DFSee, Mode=FAT, without really formatting

Hex-edit the last two byte of sector-0 (the bootsector) to be '55 AA'

Temporarily change the type to something like 0x07, until
you are going to format it.

Now, I realise that this is not a high priority issue, since eventually the 
boot will succede.
However, it can get very time consuming and frustrating, especially when 
since there may be unformatted partitions around temporarily.

Running CHKDSK in this case is NOT the solution, so the error is misleading at 
The least that could be done is just issue a SINGLE error and not repeat it 
thousands of times ...

Better would be NOT to attempt to mount the filesystem when there is no valid 
'55 AA'
signature in the bootsector.

In my tests, zeroing those two bytes in an otherwise perfectly working FAT16 
will trigger this bug/feature at the next FreeDos boot.

Regards, JvW

Jan van Wijk, author of DFSee; http://www.dfsee.com

Freedos-user mailing list

Reply via email to