[syslinux] Interaction with Windows bootloader

Gene Cumm gene.cumm at gmail.com
Mon Jan 7 12:11:37 PST 2019


On Sun, Jan 6, 2019 at 12:58 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:
>
>
> > On Sat, Jan 5, 2019 at 3:17 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:
> >
> > > > syslinux[64].exe -i -f c: bootsecfile.bss
> > > >
> > > > This should have been the form for your desire as specifying the
> > > > filename should have told it to create the BSS instead of writing it
> > > > to the VBR.  Being the "fixed" HDD instead of a removable drive like a
> > > > USB stick, "-f" is necessary.
> >
> > > Hmm, instead? Could this syntax be some kind of unintended oversight?
> >
> > Unintended oversight, unanticipated use, etc. that at least was on the
> > side of caution.  The check for fixed HDD instead of removable like
> > floppy or USB stick was put in place first.  Then the part about
> > specifying a .bss output instead of writing the VBR was added in 2004.
> >
> > > Are you saying that a command such as:
> > >
> > >  syslinux.exe -i a: bootsecfile.bss
> > >
> > > is not supposed to change the VBR of a:, whereas a command such as:
> > >
> > >  syslinux.exe -i a:
> > >
> > > performs the change of the VBR?
> >
> > Correct on both points.
> >
> > > I see several inconsistencies here.
> > >
> > > In theory, at least either --install or --Update are supposed to be
> > > required for the VBR to be modified by the installer. But for this
> > > case, since the VBR is not supposed to be modified, the --install
> > > option should not be required (for consistency with its
> > > meaning/intention).
> >
> > > Therefore, for consistency:
> > >
> > > _ A command such as:
> > >
> > >  syslinux.exe -i a: bootsecfile.bss
> > >
> > > should had meant performing both actions: writing to the VBR of a: (and
> > > copying the ldlinux.{sys,c32} files to the root of a:) _and_ writing
> > > (creating) the bss file; _not_ one action _instead_ of the other.
> >
> > Unintended changes of past behavior could have negative impacts and
> > should have been the case when the -i/-U flags were started.
> >
> > > _ A command such as:
> > >
> > >  syslinux.exe a: bootsecfile.bss
> > >
> > > should had meant writing (creating) the bss file, and copying
> > > ldlinux.{sys,c32} to the root of a:, but without writing to the VBR of
> > > a:.
> >
> > This behavior would have been preferable.
> >
> > > An additional matter, also regarding consistency, is that for the exe
> > > and com installers, the usage of --install is not yet congruent with
> > > the equivalent usage for the Linux-based installers (i.e. with and
> > > without "-i" has currently the same result for the case presented in
> > > this email thread).
> >
> > I saw this too.
> >
> > > I haven't tested the Linux-based installers with the bootsecfile
> > > option; for the exe and com installers, this syntax (that currently
> > > seems to mean "instead") is confusing and inconsistent/incongruous with
> > > the expected usage/goal of --install.
> >
> > It won't work on Linux as the saving .bss behavior is DOS/Windows only.
> >
> > > Independently of the matter of the "-f" option, isn't the above a more
> > > consistent / logical behavior (for the Windows- and DOS-based
> > > installers, at least, if not for all of them)?
> >
> > It would be preferable to have all congruent but if certain behaviors
> > are changed, it could impact someone's scripts with some potentially
> > negative impacts like breaking a system.
> >
> > I think the only safe option would be to simultaneously evaluate for
> > other changes for safety, move the .bss save to a proper option
> > (instead of being an optional extra argument) and enforce using -i/-U
> > for DOS/Windows.
> >
> > --
> > -Gene
>
> Now I'm confused.

Hopefully this helps.

> If the "-i/-U" options are not yet enforced for the exe and com
> installers, and we are discussing a case in which it should not be
> enforced, then we could choose for a different improvement: instead of
> enforcing the "-i/-U" for exe and com installers (which is currently
> not enforced), we could enforce the following combination of cases:
>
> A_ use "-i" to install to VBR; (or)
>
> B_ use "-U" to update the VBR (i.e. when the VBR is already using
> SYSLINUX); (or)
>
> C_ use the bootsecfile(.bss) option to create the bss file (and copy
> ldlinux.{sys,c32}), without touching the VBR;
>
> D_ combine either "A+C" or "B+C".

At this time "-U" is an unimplemented option for DOS/Windows.

> IOW, a command with no "-i/-U" options and simultaneously with no bss
> file, would not be accepted, but specifying either:
>
> _"-i";
> _"-U";
> _ the bss file;
> _ "-i" and the bss file;
> _ "-U" and the bss file;
>
>
> should all be possible, each of them with the respective coherent
> meaning/behavior.
>
> Moreover, since the bss file is not available for the Linux-based
> installers, then this proposal should not have any "generic" backward
> compatibility problem (since the assumed enforcement of "-i/-U" has not
> yet been implemented for Win/DOS).

"-i" works for DOS/Windows but its use isn't enforced.

> The only potential problem would be someone that has been using the
> "-i" already from Win/DOS while simultaneously using the
> bootsecfile(.bss) file option, and still doesn't want to actually
> install the code to the VBR. Could we assume that such case would be
> very uncommon, and that any changes (i.e. improvements) would be
> clearly listed in the changelog anyway?

I'd say the opposite is true.  You're unlikely to want the VBR touched
if specifying bootsecfile.

> Other than that "little" (corner?) case, where exactly the backward
> compatibility break would be happening? Am I missing / misinterpreting
> something?

That's precisely the issue.

> As a reminder, in the past there have been other changes in the options
> for the installers (e.g. --offset, "unix/linux", location of installers
> within the official archives...) and those were much more problematic
> than the case presented here. And if we go beyond the installers, we
> can find multiple backward compatibility breaks, through the history of
> Syslinux, with more impact than this one (e.g. chain.c32, multiple
> times).
>
> Could this proposal please be considered / discussed?

To be clear, unless overridden by HPA, a proposal to change
"syslinux.exe -i a: bootsec.bss" from one that does NOT install the
VBR to one that does _will_be_rejected_.  It's going from a safe
behavior to a potentially dangerous one.  If some script or program
already uses this syntax, changing its behavior risks the stability of
a system.  I see the use case for exporting the boot sector to a file
instead of the VBR as demonstrated in this discussion.

However, IF there's an actual use case for installing the VBR AND
writing it to a file at the same time, the only _safe_ method to
implement this is with a new syntax.

"syslinux.exe -i a: bootsec.bss" would either only create the
bootsecfile OR become a rejected syntax.

"syslinux.exe -i --bss bootsec.bss a:" could be a new syntax that
creates the bootsecfile and installs the VBR.  While implementing such
a new syntax, the options should be examined for any other possible
changes and we should consider rejecting syntax "syslinux.exe a:" as a
no-action syntax suggesting using "-i" to install.

-- 
-Gene


More information about the Syslinux mailing list