> 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.