> On Fri, May 23, 2014 at 8:29 AM, Ady <ady-sf at hotmail.com> wrote: > > Testing the DOS-based Syslinux installer, syslinux.com, with the "-m" > > parameter, I found that it works as expected under MS-DOS and its DOS > > variants, but it seems to fail under FreeDOS (please correct me if > > I'm wrong). > > This sounds like either a bug in FreeDOS or another undesirable > negative interaction. >My guess is that if this was a bug in FreeDOS (as in "something" that has nothing to do with the syslinux.com command) then it would be somehow triggered by other DOS programs trying to write to the MBR. Considering that there are several (open source) DOS programs that are capable of successfully writing to the MBR under FreeDOS, I would tend to think that there is some interaction issue.> I vaguely recall FreeDOS having some sort of HDD-acceleration > (caching/prefetching). A quick Google returns "lbacache" and > "uide.sys". If so, a test should be run without either running. >I ran syslinux.com under a "clean" FreeDOS environment. Even config.sys and autoexec.bat (or their FreeDOS equivalents) are empty, so other than the kernel and the shell, there is nothing there. I also tested at least one case with multiple drivers loaded and the result was equivalent: The "-m" argument wrote on the VBR, not on the MBR.> > Using FreeDOS kernel v.2041 (386f32), Syslinux v.6.03-pre11 and > > either FAT16 or FAT32 partitions, executing: > > syslinux.com -m -i c: > > > > or: > > syslinux.com -f -m -i c: > > > > will not write to the MBR, and will ruin the VBR. > > > > To be clear, the "-m" parameter overwrites parts of the VBR. > > > > If, *instead*, I use the same versions with the command: > > > > syslinux.com -i c: > > > > (without the "-m" parameter, optionally with "-f" if needed) then it > > works correctly, installing SYSLINUX on the VBR. > > > > Unfortunately, once the "-m" parameter is used, repairing the VBR > > seems to be not so simple as executing the command again without the > > "-m" parameter. Additional tests might be needed so to find out the > > reason. > > This is expected as the VBR is now technically corrupt and you'll need > the backup VBR if present. >Indeed, the basic values (fields) in the FAT VBR have been overwritten by using "-m" (and "-f" if needed), including the sector size field (among others), so the damage in the VBR is not (only) on the booting code.> > I have not tested what would happen if I avoid using "-i". I don't > > know if it would make any difference. > > It should balk with an error and refuse to do anything since there's > no action specified (install regardless or upgrade only if > SYSLINUX/EXTLINUX already exists). > > > Several combinations of different versions of FreeDOS with different > > versions of Syslinux have not provided better results (in fact, in > > some cases they were worse). > > > > I admit it is also possible that I am making some mistake. I would > > appreciate if someone could try to replicate this behavior. > > Your test sound valid to me. >Since I tried several combinations of FreeDOS (and MS-DOS) and Syslinux versions, and initially I wasn't expecting this error, I *might* have made some mistake (PEBKAC ID10T error). Or perhaps some particular details in my tests are triggering the problem under FreeDOS but not under MS-DOS (let's say, CHS values, or the size the FAT partition, or partition alignment, or VM configuration, or...). I was hoping that someone could attempt the test, perhaps with a different result so it would narrow down the problem.> > I hope syslinux.com can be improved so to make it more compatible > > with FreeDOS, not just with MS-DOS. > > -- > -Gene >TIA, Ady.
On 05/24/2014 01:58 PM, Ady wrote:> > My guess is that if this was a bug in FreeDOS (as in "something" that > has nothing to do with the syslinux.com command) then it would be > somehow triggered by other DOS programs trying to write to the MBR. > Considering that there are several (open source) DOS programs that > are capable of successfully writing to the MBR under FreeDOS, I would > tend to think that there is some interaction issue. >There are a few different ways to do this. I suspect programs like FDISK use direct BIOS accesses, because they have to also create partitions. Syslinux uses INT 21, AX=440D, CH=08/48 CL=41/61 which to the best of my understanding is supposed to read the absolute sectors corresponding to a target device, and I just verified under MS-DOS 6.22 behaves that way, and that FreeDOS 1.1 does not -- which by definition means it is a bug in FreeDOS. -hpa
perditionc at gmail.com
2014-May-30 04:25 UTC
[syslinux] Syslinux DOS-based installer in FreeDOS
On Sat, May 24, 2014 at 11:22 PM, H. Peter Anvin <hpa at zytor.com> wrote:> On 05/24/2014 01:58 PM, Ady wrote: > > > > My guess is that if this was a bug in FreeDOS (as in "something" that > > has nothing to do with the syslinux.com command) then it would be > > somehow triggered by other DOS programs trying to write to the MBR. > > Considering that there are several (open source) DOS programs that > > are capable of successfully writing to the MBR under FreeDOS, I would > > tend to think that there is some interaction issue. > > > > There are a few different ways to do this. I suspect programs like > FDISK use direct BIOS accesses, because they have to also create > partitions. > > Syslinux uses INT 21, AX=440D, CH=08/48 CL=41/61 which to the best of my > understanding is supposed to read the absolute sectors corresponding to > a target device, and I just verified under MS-DOS 6.22 behaves that way, > and that FreeDOS 1.1 does not -- which by definition means it is a bug > in FreeDOS. > > -hpa > >Thank you both, for finding the bug and narrowing down to the specific calls at fault. I have posted a preliminary fix (see https://sourceforge.net/p/freedos/bugs/121/ ). Kenneth J. Davis