[syslinux] Can Syslinux install another USBstik ?

[Gene Cumm]

On Mon, May 1, 2017 at 4:36 AM, eas lab via Syslinux <syslinux at zytor.com> wrote:
> When a USBstiked-syslinux starts, it's the PC's firmare that's reading
> the USB ?.

Yes.

> But once the USBsyslinux takes over, has IT also got a USB driver?

Nope, the PC's firmware provides an API that makes it look like a
generic floppy or hard drive.

> So that USBsyslinux can install a different USBstik/partition?
> Ie. boot with stikA to install & run stikB:partition5 ?

Do you mean boot SYSLINUX from stik-A but then load files like a
kernel/initrd from stikB:partition5?  It's possible but only from a
development version of Syslinux that has the multifs patch merged.

> ------------ Is the following sound logic?
>> Do zero out the partition table first so you don't "inherit" any
>> badness ("dd if=/dev/zero of=/dev/sdx bs=512 count=1 conv=sync").
>> Actually before destroying the partition table, I'd zero out the
>> beginning of all and any partitions ("dd if=/dev/zero bs=1024k
>> count=10 conv=sync of=/dev/sdxX" x Y) first, as we are in starting
>> from scratch mode. (If there were RAID/GPT involved I'd zero out
>> the end of partitions/disk respectively too.)

For HDDs, I might take a route of zeroing some things but I've had
quite mixed results in the past with trying to create my own geometry
on USB sticks although it's been long enough I can't recall what
versions nor what computers this was on (other than a brand).  If I'm
looking to really make a clean slate, I probably wouldn't zero the
beginnings of each partition then the head and tail of the disk and
just zero the entire disk, partially out of ensuring a clean slate and
partially because it's just easier (though scriptable if someone wants
to write it).

> CPU reading a memory location is not like human reading from paper.
> <zero> bytes are no more "nothing" than any of the other possible
> 255 values.
>   Of course the system can be programed:
>    IF <there are more than N consecutive zero-bytes> THEN .....
> but, that's unlikely ?

On x86, 0x00 is a real instruction unfortunately.  If I recall
correctly, once you take a second 0x00 byte in, it's "ADD [BX+SI], AL"
(16b mode) or "ADD [EAX], AL" (32b mode).  On some other platforms,
0x00 is the No-Operation Op-code (aka NOP or NOOP).  Since 0x00 is a
legitimate instruction, counting is certainly useless.  Also, to do
this, you'd need an extra register of ~ log2(N) bits to count this.

-- 
-Gene