> ]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.
] At this time, Syslinux by itself cannot boot files located on a ] different filesystem volume. Finally an answer to my simple question - PERHAPS? What is a "filesystem volume" ? Why do you change the terminology/definitions of the original question? Is a "different filesystem volume" on a different <physical device>? ] Using chain.c32, you can load a boot sector (MBR or VBR) located on ] another device. Thanks for calling it "another device". I can't relocate the Dir with the files; but IIRC one was *.32. Perhaps it's a 32/64bit problem? ] 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). No!! I deliberately avoided confusing you, and only listed sufficient for you to see: 1. it *IS* about syslinux; 2. the date [syslinux-model]; 3. that I had been editing the original cfg-text; ] 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. I had at least 3 sets-of-kernel & initrm on the capable boot-stik, which I could edit at boot-time to select - as you describe below. Plus a score of all-but-one commented out line: containing the parameters. ] 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. Reading my text: do you think I didn't know that <sdX moves around>; that's why LABEL/UUID is used. And why I bypassed that problem, by asking the general/principle question: "can *ANY* bootstikA boot a bootstikB". Your description above approximately describes how I in fact booted different IDE & SATA from a USBstik, which indicates that your original statement is false. There are multiple layers of complexity: 1. can USBstikA boot ANY other device? Yes: as you partially describe. 2. can USBstikA boot USBstikB? This forum refuse or incapable to answer. 3. can USBstikA boot a USB-adaptor-connected IDE or SATA. Must 1st pass "2"
[quoted lines from Ady Ady]:> 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.Maybe I can try to shed some light here. The files listed in the "old" USB are probably written by this script: http://ftp.slackware.com/pub/slackware/slackware-14.1/source/a/pkgtools/scripts/setup.80.make-bootdisk or similar, which is intended to write a bootable USB stick to be used in case of emergency, e.g. if for some reason the installed system can not be booted by the regular bootloader. Here is the content of the only partition on boot script after having run the script: --- root[/mnt]# tree . ??? EFI ? ??? BOOT ? ??? BOOTX64.EFI ? ??? elilo.conf ? ??? message.txt ??? f1.txt ??? ldlinux.sys ??? message.txt ??? syslinux.cfg ??? vmlinuz --- And: --- root[/mnt]# cat syslinux.cfg default vmlinuz root=/dev/sdb2 vga=normal ro prompt 1 timeout 6000 display message.txt F1 f1.txt F2 message.txt #F3 f3.txt #F4 f4.txt #F5 f5.txt #F6 f6.txt #F7 f7.txt label mount kernel vmlinuz append root=/dev/sdb2 vga=normal ro --- And: --- root[/mnt]# cat message.txt Welcome to the Slackware Linux custom USB boot stick! By default, this stick boots a root Linux partition on /dev/sdb2 when you hit ENTER. If you'd like to boot some other partition, use a command like this on the prompt below: mount root=/dev/sda1 ro Where "/dev/sda1" is the partition you want to boot, and "ro" specifies that the partition should be initially mounted as read-only. If you wish to mount the partition read-write, use "rw" instead. To set the video console mode, use the vga= parameter (press F1 to see a table). You may also add any other kernel parameters you might need depending on your hardware, and which drivers are included in your kernel. --- So there is just a kernel to boot and indeed no chain.c32. Please note that there is no "rootdelay" or "rootwait" kernel parameter by default. In some cases (e.g. USB connected hard disk) this can result in a not ready root partition when it's needed in the boot sequence. So the intended usage of the boot stick is: _ plug in the stick and (re)boot _ (this displays message.txt) _ the user can then edit the command line... _ then press [Enter] So IMHO this *should* allow to boot a system whose root partition is on an USB stick, provided that: _ the kernel (vmlinuz) written on the USB stick include the neede drivers (I am not sure that it be the case for the version used by the OP), as the stick does not include an initramfs with the relevant modules, _ the root partition's name be correct, _ possibly a "rootdelay" or "rootwait" kernel parameter be appended to the command line. Didier PS I see that the content of the USB stick and of message.txt posted by the OP differ from what I posted. I don't know why, but I don't think that changes the big picture. To answer a question from the OP: yes, all Slackware installers ship the lsblk command. This not too heavy ISO image also does, so you can use it for that: http://slint.fr/testing/fake_slackware64-14.2-2.iso To check its integrity: http://slint.fr/testing/fake_slackware64-14.2-2.iso.md5 Signatures: http://slint.fr/testing/fake_slackware64-14.2-2.iso.asc http://slint.fr/testing/fake_slackware64-14.2-2.iso.md5.asc My public key is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x60C03EEA.asc Type: application/pgp-keys Size: 1718 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20170614/ff197b95/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://www.zytor.com/pipermail/syslinux/attachments/20170614/ff197b95/attachment.sig>
Le 14/06/2017 ? 17:53, Didier Spaier a ?crit :> [quoted lines from Ady Ady]: > To answer a question from the OP: yes, all Slackware installers ship > the lsblk command. This not too heavy ISO image also does, so you can > use it for that:Forgot to tell: the ISIO image is hybrid thus can be dd'ed to an USB stick.
Le 14/06/2017 ? 17:53, Didier Spaier a ?crit :> > So IMHO this *should* allow to boot a system whose root partition is on > an USB stick, provided that: > _ the kernel (vmlinuz) written on the USB stick include the neede > drivers (I am not sure that it be the case for the version used by the > OP), as the stick does not include an initramfs with the relevant > modules, > _ the root partition's name be correct, > _ possibly a "rootdelay" or "rootwait" kernel parameter be appended to > the command line.Re-reading this maybe I was not clear enough: _ The syslinux stuff and a kernel are on on USB stick A. _ The root partition of the system we want to boot is on another USB stick (USB stick B). Among the conditions I forgot to mention that the arch of the kernel in USB stick A should be the same as that of the system in USB stick B. (64/64 or 32/32). Didier