Re: [Freedos-user] More FreeDOS FDISK tests - failure is repeatable
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 you worry, borrow the FDISK only from MS-DOS, and others use FreeDOS. Rgds, Johnson. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] re: More FreeDOS FDISK tests - failure is repeatable
Hi, I think you will be safe as you apply FDISK to NEW harddisks: The problem is only that if you get a read error while reading the existing partition scheme, our FDISK has the stupid strategy to write a new empty partition table as automatic solution. Your new PCs should not show read errors and writing an empty partition table will not cause problems as your PCs are still empty anyway. However, I recommend that you first test whether FDISK recognizes your harddisks - I assume that all 30 PCs are the same style of hardware. It will probably work better if you load only HIMEM but do not load EMM386 before. Whether it will work better or worse with UDMA2 loaded, no idea. At least FORMAT will be fast anyway, as the default is NOT to wipe the whole drive - it defaults to just writing empty FAT and root directory data. Eric --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] announce: devload 3.14
Hi, Eric Auer escribió: Please test if your devices can still be loaded with the new DEVLOAD version (DEVLOAD allows you to load devices from the prompt which otherwise would be loaded with DEVICE= or DEVICEHIGH=, but note that UMB support is limited, memory drivers like HIMEM / EMM386 should not be loaded with DEVLOAD and that using DEVICE= is still the official way while DEVLOAD is just a convenient cheat to load drivers later). It is ok that it is convenient, even otherwise-pointless, to load HIMEM and EMM386 within CONFIG.SYS, so that other devices, DOS Initialization can make true use of UMBs and such, but is there a technical reason, appart from being hibrid drivers, not to be able to load them with DEVLOAD? Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] More FreeDOS FDISK tests - failure is repeatable
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 drive configuration. There are plenty of other solutions... I recommend using one of them instead of FreeDOS FDISK. :-( Mark 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, so this bug only happens with faulty hard-drives or file-systems? 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. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] More FreeDOS FDISK tests - failure is repeatable
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 further prompting -- FDISK calls the Create_MBR_If_Not_Present() routine. NO. Please, no. You should never write to the hard disk for low-level stuff like partitions and master boot record data without warning and giving the user a chance to abort or decide not to do it. Second related issue...the Create_MBR_If_Not_Present() routine receives an error code if Read_Physical_Sectors() routine fails, but the error code is not checked. Consequently, should the routine to read physical sectors fail for any reason and return an error, the following occurs: The buffer which was not loaded by the read is still tested for valid values and if they fail to match what was expected (as they likely will) a new MBR is written. That is probably the wrong approach to handling an error on the low-level disk read. Particularly at startup. 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 Currently I have it so it delays actual writing of MBR to disk until just before program exit (so if you reboot or in advanced mode abort your changes, the mbr=CHS(0,0,1) should be unmodified). It also now aborts on read error with a message. Note: fdisk may still write to other sectors than mbr during use, eg boot sector of partition. This build also has a pause and message that shows the disks the MBR is being written to. I'll continue working on this a little while longer, but this build is here for feedback. Jeremy --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] More FreeDOS FDISK tests - failure is repeatable
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. There are no EMM386 interactions to interact with and no reported outstanding errors with EMM386. EMM386 plain wasn't running _anything_ by the end of your tests. What seems most likely based on current evidence is that the memory used by EMM386 when it is loaded, or the resultant memory image remaining after it is loaded, is triggering a problem within FDISK. Or possibly there is a multi-way interaction of drivers, kernel, and FDISK. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
