> ]You seem to be assuming that changing from a direct SATA and IDE
> ] connections to some USB adapter would have no impact on how the
> ] respective HDDs are recognized/detected by the BIOS.
>
> ] You seem to be
> ] assuming that the BIOS from 2 different PCs/Laptops would recognize all
> ] your devices in the same exact way and that there would be no changes
> ] in behavior or in supported features by the respective BIOS.
>
> ] Generally speaking, these
> *WRONG* [when I wanted to buy it: I doubted I could read linux SATA]
> ] assumptions are not necessarily valid. There
> ] might be some particular case(s) in which, by coincidence, your whole
> ] hardware is "portable", but this is not a _generic_ situation.
There
> ] might be some way to overcome potential differences, but we don't
have
> ] any relevant information at this time in order to guide you in any way.
>
> Since SYSLINUX was designed by the controllers of this forum, the
> "Information" asked for does not need eg. discovery of a
hidden/unknown
> diseases.
>
> ] Please also have in mind that this is the Syslinux Mailing List, and
> ] there is some practical limit as to how much guidance users can receive
> ] here about "whatever boot problem in the world might exist". At
this
> ] point, there is no detail/information that actually indicates that
> ] there is some issue related to Syslinux in your situation; explicit
> ] clear information would help.
>
> My starting point was the *SYSLINUX* partial dir-listing; to PROVE that
> the issue is directly syslinux related. I'm free to ignore syslinux and
> use other methods; except that the old SYSLINUX booter proved itself well
> under the previous configuration. Also TC64's syslinux booter works
well.
>
> ] Are you currently able to boot these OSes in any way?
>
> Currently can only boot:
> TinyCore64 Linux from stik1;
> Debian7-64bit from stik2 via GRUB;
> Debian7-32bit stik3 - got <damaged>.
> IDE & SATA & usbToshiba can only be`chroot`-ed to via adaptor.
>
> ] When trying your USB boot stick, what exactly do you see? What's the
> ] behavior? What do you do and in which way it "fails"?
>
> Imagine the size of the logs of my testing, compared to the simple
> explanation that I've so far failed to convey?!
>
> Can you read and answer the simple question of the SUBJECT of this thread,
> from a THEORETICAL perspective?
>
> ---- Cut irrelevant questions -------------
I understand your frustration. Unfortunately, you still have not
provided the relevant information in order to help you, even though you
think you have.
At this time, Syslinux by itself cannot boot files located on a
different filesystem volume.
Using chain.c32, you can load a boot sector (MBR or VBR) located on
another device. Since the list of files located in your boot stick did
not include chain.c32, my assumption (and not only mine, if you
carefully read some of the prior replies) is that the relevant "old"
files (e.g. kernel, initrams, etc.) were also located in the same old
(stolen) boot stick (while your root partition might have been located
on a different device).
But, since you have not provided any relevant information (not even the
content of your old syslinux.cfg nor how exactly you were "editing"
your boot entries so as to boot some/one OS or another), the above
paragraphs are only assumptions. In a similar way, prior replies to you
were also theoretical and very generic.
For example, your old Slackware's kernel (+ initrd files) might had
been located in the same boot stick, and the boot command _might_ had
included some indication for the kernel (+ initrd) to find the "root"
partition (e.g. root=/dev/hdb5 or something else). But, as I tried to
explain before, this "hdb5" varies depending on the BIOS; in other
words, it is not always "portable" when changing connections or when
moving to another PC.
I hope you find some way to access your OS/files, whether with Syslinux
or with some other bootloader.
Good luck,
Ady.