Kenneth J. Davis wrote:
...
I have a work in progress towards fixing these issues of fdisk,
to try my current build - http://www.fdos.org/kernel/test/fdisk.exe
I have updated the fdisk executable above.
- Changes from 1.2.1 version (see fdisk.diff at same location):
From Eric, it has some chan
--- Gerry Hickman <[EMAIL PROTECTED]> wrote:
> It's just I have to build 30 PCs in coming weeks,
> plus some production
> servers, and plan to use FreeDOS FDISK to partition
> them. I was a bit
> worried reading about this bug, but all my hard
> drives are brand new, so
> should be OK.
I wou
At 03:29 PM 7/23/2005 +0100, Gerry Hickman wrote:
Biggest mitigating factors are that if your hard drive behaves without
errors, is reasonably standard with expected parameters, and there is no
corruption of the program, the MBR write on startup won't occur.
Ah, so this bug only happens with
At 11:33 PM 7/23/2005 +, you wrote:
This may be a side effect of memory corruption with EMM386. In
fact, it appears to be a result of some interaction with EMM386.
I do not believe the hard disk in question is faulty and I do not
believe that it has non-standard parameters.
Doubtful. Ther
Michael Devore wrote:
At 04:01 PM 7/21/2005 -0500, I wrote:
When you invoke FDISK without arguments, it goes into the
Interactive_User_Interface() routine. That, in turn, asks about FAT32
support, via Ask_User_About_FAT32_Support() function. OK so far.
After that call -- without any furth
This may be a side effect of memory corruption with EMM386. In
fact, it appears to be a result of some interaction with EMM386.
I do not believe the hard disk in question is faulty and I do not
believe that it has non-standard parameters.
I do not believe the memory corruption is due to the hard
On Sat, 23 Jul 2005 15:29:04 +0100, you wrote:
Hi Gerry,
>It's just I have to build 30 PCs in coming weeks, plus some production
>servers, and plan to use FreeDOS FDISK to partition them. I was a bit
>worried reading about this bug, but all my hard drives are brand new, so
>should be OK.
If y
Hi Michael,
If it's always been there, why have more people not been affected?
Biggest mitigating factors are that if your hard drive behaves without
errors, is reasonably standard with expected parameters, and there is no
corruption of the program, the MBR write on startup won't occur.
Ah
At 08:36 PM 7/22/2005 +0100, Gerry Hickman wrote:
[EMAIL PROTECTED] wrote:
By the way, I consider this bug extremely serious.
I agree, and Michael's post would appear to confirm that FDISK is far from
read-only, but has this bug always been there, or is it only in recent
development builds
[EMAIL PROTECTED] wrote:
By the way, I consider this bug extremely serious.
I agree, and Michael's post would appear to confirm that FDISK is far
from read-only, but has this bug always been there, or is it only in
recent development builds?
If it's always been there, why have more people
Anyone know if Brian is on fd-user list? or otherwise been notified of
these issues?
I don't think it will be too difficult to correct (warn/abort at least)
so maybe if I get time after work tommorrow I'll make a patch available
to make fdisk safer to use.
Thanks for reviewing the code,
Jere
On Thu, 21 Jul 2005 16:21:46 +0200, you wrote:
Hi,
>DEVICE=HIMEM.EXE
>DEVICE=UDMA2.SYS
>DEVICE=EMM386.EXE NOEMS X=A000-EFFF MEMCHECK VDS
>
>-or-
>
>DEVICE=HIMEM.EXE
>DEVICE=EMM386.EXE NOEMS X=A000-EFFF MEMCHECK
>
>I'm not searching for to blame a component, too many factors involved.
Better remo
I agree. It is far too risky to run the FreeDOS FDISK under any
circumstances - just based on the limited tests I have done.
I will run it ONLY on this test computer. It becomes even
more of an adventure given your analysis of the source code! :-)
Mark
> At 11:40 PM 7/21/2005 +, Mark w
At 11:40 PM 7/21/2005 +, Mark wrote:
Are any of the tests that have been suggested (other kernels,
MS-DOS, ommitting VDS, trying UDMA2, older versions of
FDISK, etc.) going to help in getting this problem fixed? I have
a repeatable problem (always a good thing) and have, I think,
done a pre
> By the way, I consider this bug extremely serious.
> The worst possible bug would trash the data instead of
> just the partition table, but this one is close! I'd be
> suprised if the FreeDOS project had very many that were
> more critical.
I tend to agree. Had a simlar bug been found "back in
Hi Michael et al:
Fiddling with this is very time consuming and a bit risky. Though,
so far, it has only been the partition table that has gotten
clobbered. And, only one machine that I know of appears to
have permanently lost all of its data as a result. The rest
have been recoverable using Li
At 04:01 PM 7/21/2005 -0500, I wrote:
When you invoke FDISK without arguments, it goes into the
Interactive_User_Interface() routine. That, in turn, asks about FAT32
support, via Ask_User_About_FAT32_Support() function. OK so far. After
that call -- without any further prompting -- FDISK ca
At 03:11 PM 7/21/2005 +, Mark wrote:
I'll try that. I'm only willing to run this on the one computer...too
risky for any others. I'm not blaming fdisk, but do not consider
running it safe. If I do not run fdisk, the disk partition table does
not get destroyed!
Well, maybe I'm wrong and
Hi,
It seems to me there are three possible reasons for the corruption:
1. Something is up with FDISK
2. Some config is corrupting the memory (e.g. EMM386)
3. Something is a big different with the BIOS or hardware in this machine
Before switching to FreeDOS, I was experiencing similar problems
Hi Bernd:
I'll try that. I'm only willing to run this on the one computer...too
risky for any others. I'm not blaming fdisk, but do not consider
running it safe. If I do not run fdisk, the disk partition table does
not get destroyed!
Mark
> [EMAIL PROTECTED] schreef:
> > Ok, I just added edi
[EMAIL PROTECTED] schreef:
Ok, I just added edit.exe to my boot floppy! :-)
First, modifying config.sys to:
a:\device=himem.exe
a:\device=emm386.exe noems X=a000-efff memcheck vds
EMM386 reports "no suitable UMB memory block found" :-)
FDISK shows a bunch of garbage after "Do you want to use
At 12:05 AM 7/21/2005 +, Mark wrote:
Make config.sys
a:\device=himem.exe
Reboot.
The DIR commands now work. Reboot again.
Kernel still recognizes the partitions. emm386.exe not run.
FDISK did NOT trash my MBR. Bare himem.
Doesn't make much sense. EMM386 is effectively out of the pic
Ok, I just added edit.exe to my boot floppy! :-)
First, modifying config.sys to:
a:\device=himem.exe
a:\device=emm386.exe noems X=a000-efff memcheck vds
EMM386 reports "no suitable UMB memory block found" :-)
FDISK shows a bunch of garbage after "Do you want to use
large disk (FAT32) support (
At 12:37 AM 7/21/2005 +0200, Bernd Blaauw wrote:
[EMAIL PROTECTED] schreef:
Meanwhile, personally, I don't recommend using FreeDOS FDISK! :-(
Mark
I hope you have the option of using FreeDOS FDISK running under as many MS
components as you can (kernel, shell, himem, emm386). A Win98 bootdis
Hi Bernd:
I don't believe it is just FDISK. It appears to be FDISK + EMM386,
maybe plus the development kernel. However, until this is
isolated and the cause understood, I do not recommend
using it. There are other tools which do the same thing! :-)
Mark
> [EMAIL PROTECTED] schreef:
> > Mea
[EMAIL PROTECTED] schreef:
Meanwhile, personally, I don't recommend using FreeDOS FDISK! :-(
Mark
I hope you have the option of using FreeDOS FDISK running under as many
MS components as you can (kernel, shell, himem, emm386). A Win98
bootdisk for example.
Just to be absolutely sure it's
OK. Back to the standard development kernel.
config.sys still has himem.exe and emm386.exe. No
autoexec.bat.
Boot floppy without running FDISK. Reboot Linux. Partition table normal.
Copy it to the floppy this time! :-)
Reboot FreeDOS from floppy.
A:> fdisk
Displays a bunch of garbage
27 matches
Mail list logo