Good afternoon all! I have a project I'm working on that requires Linux to be installed either to its own partition, or to the partition of a host OS (Windows or Linux). One way works, the other way does not... Use Case 1: In this scenario, Linux is installed to its *own* partition as is syslinux (syslinux -i /path/to/syslinux/files). Afterwards, I 'dd' the first 512bytes of that partition as the .bss file to chainload from the host OS bootloader. This method works for all tested host OS's including Windows. Use Case 2: In this scenario, Linux is installed to the *same* partition as the host OS. If the host OS is Linux, I just add the option of booting our software to the existing bootloader - everything works fine in this situation. If the host OS is Windows, I have problems... If possible, I would like to have syslinux generate the .bss data as a file instead of writing to the partition. This will retain the existing Windows bootloader while allowing me to chain load the file generated. Looking at the online documentation, there is an optional value for the 'bootsecfile', but I can't get it to work. I have tried: syslinux[64].exe -i "/path/to/syslinux/file" c: bootsecfile.bss syslinux[64].exe -i "/path/to/syslinux/file" c:\bootsecfile.bss syslinux[64].exe -i "/" c: bootsecfile.bss syslinux[64].exe -i "/" c:\bootsecfile.bss syslinux[64].exe -i c: bootsecfile.bss syslinux[64].exe -i c:\bootsecfile.bss I either get an error "Not a removable drive (use -f to override)", or a returned listing of all the switches that can be passed to the executable. With none of those attempts working, I tried to just install syslinux to the partition so I could generate the .bss file using the first 512bytes of the Windows partition, but I can't get syslinux to install. I've tried: syslinux[64].exe -i "/path/to/syslinux/file" c: syslinux[64].exe -i "/" c: syslinux[64].exe -i c: The results are the same as the prior attempts. It appears that I can't even install syslinux on a Windows partition. Any help would be appreciated! Also, this is on a Windows 7 OS (but will also need to work with modern versions including Windows 10). Thanks, Dave
On Thu, Jan 3, 2019 at 12:31 PM David Henderson via Syslinux <syslinux at zytor.com> wrote:> > Good afternoon all! I have a project I'm working on that requires > Linux to be installed either to its own partition, or to the partition > of a host OS (Windows or Linux). One way works, the other way does > not...For starters, what version? Official pre-compiled binaries?> Use Case 1: > In this scenario, Linux is installed to its *own* partition as is > syslinux (syslinux -i /path/to/syslinux/files). Afterwards, I 'dd' > the first 512bytes of that partition as the .bss file to chainload > from the host OS bootloader. This method works for all tested host > OS's including Windows. > > > Use Case 2: > In this scenario, Linux is installed to the *same* partition as the > host OS. If the host OS is Linux, I just add the option of booting > our software to the existing bootloader - everything works fine in > this situation. If the host OS is Windows, I have problems... > > If possible, I would like to have syslinux generate the .bss data as a > file instead of writing to the partition. This will retain the > existing Windows bootloader while allowing me to chain load the file > generated. Looking at the online documentation, there is an optional > value for the 'bootsecfile', but I can't get it to work. I have > tried: > > syslinux[64].exe -i "/path/to/syslinux/file" c: bootsecfile.bss > syslinux[64].exe -i "/path/to/syslinux/file" c:\bootsecfile.bss > syslinux[64].exe -i "/" c: bootsecfile.bss > syslinux[64].exe -i "/" c:\bootsecfile.bss > syslinux[64].exe -i c: bootsecfile.bss > syslinux[64].exe -i c:\bootsecfile.bsssyslinux[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. However, IF and only if you specify a bootsecfile and don't specify to modify the VBR or MBR (ie don't do either install an MBR OR activate the partition), I could see a mild feature enhancement to remove that particular check.> I either get an error "Not a removable drive (use -f to override)", or > a returned listing of all the switches that can be passed to the > executable. > > With none of those attempts working, I tried to just install syslinux > to the partition so I could generate the .bss file using the first > 512bytes of the Windows partition, but I can't get syslinux to > install. I've tried: > > syslinux[64].exe -i "/path/to/syslinux/file" c: > syslinux[64].exe -i "/" c: > syslinux[64].exe -i c: > > The results are the same as the prior attempts. It appears that I > can't even install syslinux on a Windows partition. Any help would be > appreciated! Also, this is on a Windows 7 OS (but will also need to > work with modern versions including Windows 10).Likely the same, "-f" is necessary.> Thanks, > Dave-- -Gene
> 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? 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? 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. _ 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:. 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 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. 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)? Regards, Ady.
Good morning everyone, thanks for getting back in touch with me about this. I see there is quite a discussion going on, so I'll add my $0.02 while answering any questions I can. Also, I should be able to attempt some of these answers today and report back... On 1/5/19, Gene Cumm <gene.cumm at gmail.com> wrote:> On Thu, Jan 3, 2019 at 12:31 PM David Henderson via Syslinux > <syslinux at zytor.com> wrote: >> >> Good afternoon all! I have a project I'm working on that requires >> Linux to be installed either to its own partition, or to the partition >> of a host OS (Windows or Linux). One way works, the other way does >> not... > > For starters, what version? Official pre-compiled binaries?The version in Linux is 6.03, the version on Windows is also 6.03. And yes, these are from pre-compiled binaries (via TinyCore repo). ...snip...>> value for the 'bootsecfile', but I can't get it to work. I have >> tried: >> >> syslinux[64].exe -i "/path/to/syslinux/file" c: bootsecfile.bss >> syslinux[64].exe -i "/path/to/syslinux/file" c:\bootsecfile.bss >> syslinux[64].exe -i "/" c: bootsecfile.bss >> syslinux[64].exe -i "/" c:\bootsecfile.bss >> syslinux[64].exe -i c: bootsecfile.bss >> syslinux[64].exe -i c:\bootsecfile.bss > > 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. > > However, IF and only if you specify a bootsecfile and don't specify to > modify the VBR or MBR (ie don't do either install an MBR OR activate > the partition), I could see a mild feature enhancement to remove that > particular check.I'll give this a shot and report back! ...snip...>> 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.Would it be possible to add this behavior to the Linux version. It would save me from having to do additional steps with 'dd' instead of just exporting to a file in that environment. Plus this would make usage syntax between Linux and Windows closer to one another. ...snip...>> 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.Is '-U' even needed? Why wouldn't someone just re-create the file calling 'syslinux -i ...' again? ...snip...>> 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.I would agree. When I first read through the syntax, I thought adding a .bss file to the call would prevent writing to the VBR (which was undesired) and just output to a file (which was desired). ...snip...> 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.If nobody has presented a case for writing to the VBR *and* file at the same time, I would think it is safe to assume that this behavior would be very rare, if at all. They could also accomplish this by just making two calls 'syslinux -i a:' and 'syslinux -i bootsecfile.bss'. Alternatively, it does save time/effort having the ability to perform both options in a single call... Additionally... - When specifying '-i' without a path, syslinux assumes to the install the ldlinux.sys/c32, etc files in the root of the partition, whereas specifying a path places those files at that location correct? - If you do intend to add a '-b' switch, I would suggest to make sure the documentation is clear on what each does. For example: -i installs over the current boot sector of the partition -b installs to a boot sector file rather than the partition I'll leave the combining of the options up to others as I have no preference either way at this point. Thanks, Dave