Syslinux - Mar 2017 - "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

> 
> I ponder whether it would be possible to create a diagnostic MBR
> which does not necessarily have to boot but rather tells what the
> isohybrid MBR would perceive: Presence of partition table,
> EBIOS or CBIOS, block address used with INT 13, content of the block
> read by the first INT 13, ...
> 
> One could preserve the isohybrid MBR of an ISO and replace it by
> the diagnostic one for testing purposes:
> 
>   dd if=/dev/sdc bs=1 count=512 of=isohybrid_mbr.bin
> 
>   dd of=/dev/sdc bs=1 count=432 if=diagnostic_mbr_code.bin
> 
> The diagnostic MBR should only use 432 bytes because at byte 432
> to 435 of the isohybrid MBR there is the 512-byte-block address of
> file isolinux.bin, which was patched in by isohybrid or xorriso.
> So the code would be able to work with any isohybrid ISO.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
You might be interested in:
 http://repo.or.cz/syslinux.git/tree/HEAD:/diag 

which ATM generate "handoff.bin and at least 2 geodsp*.{bin,img(gz)}.

Please note that these were not intended specifically for ISOLINUX / 
ISO9660, yet you might still find them useful(?).

As I mentioned before, there is also "isolinux-debug.bin", but it is 
not supported by isohybrid, AFAIK.

Regards,
Ady.

Hi,

Ady wrote:
>  http://repo.or.cz/syslinux.git/tree/HEAD:/diag 
> "handoff.bin
This does not look like it would tell much of the properties in question.
Nevertheless its print functions might be of interest for an isohybrid
diagnostic MBR.

> and at least 2 geodsp*.{bin,img(gz)}
I am now reading
  http://repo.or.cz/syslinux.git/blob/HEAD:/diag/geodsp/README

These programs could probably tell the perceived disk geometry factors
for cylinders and heads by the first line. I understand they also make
test reads of their own bytes in order to verify that addressing is
correct.

So yes, it would be interesting to see the output of geodspms.img
or geodsp1s.img. The README is unclear about which one should be
copied to the stick. Possibly one has to try both.

Next question is where a Debian user gets the images geodsp1s.img.xz
and geodspms.img.xz. "apt-file search geodsp" finds nothing on
"jessie"
or "testing". Debian "wheezy" had them as:
  /usr/lib/syslinux/diag/geodsp1s.img.xz
  /usr/lib/syslinux/diag/geodspms.img.xz
I guess one would have to pull them out of the package available at
  https://packages.debian.org/wheezy/all/syslinux-common/download

Is there an official SYSLINUX URL where to get the images ?

> As I mentioned before, there is also "isolinux-debug.bin", but it
is
> not supported by isohybrid, AFAIK.
The problem is not in the El Torito image, except the fact that its
alleged first sector does not bear the magic number.
Of course, "isolinux-debug.bin" is not supposed to bear the magic
number
of an isohybrid capable El Torito image at all.


Have a nice day :)

Thomas

> Hi,
> 
> Ady wrote:
> >  http://repo.or.cz/syslinux.git/tree/HEAD:/diag 
> > "handoff.bin
> 
> This does not look like it would tell much of the properties in question.
> Nevertheless its print functions might be of interest for an isohybrid
> diagnostic MBR.
> 
> 
> > and at least 2 geodsp*.{bin,img(gz)}
> 
> I am now reading
>   http://repo.or.cz/syslinux.git/blob/HEAD:/diag/geodsp/README
> 
> These programs could probably tell the perceived disk geometry factors
> for cylinders and heads by the first line. I understand they also make
> test reads of their own bytes in order to verify that addressing is
> correct.
> 
> So yes, it would be interesting to see the output of geodspms.img
> or geodsp1s.img. The README is unclear about which one should be
> copied to the stick. Possibly one has to try both.
> 
> Next question is where a Debian user gets the images geodsp1s.img.xz
> and geodspms.img.xz. "apt-file search geodsp" finds nothing on
"jessie"
> or "testing". Debian "wheezy" had them as:
>   /usr/lib/syslinux/diag/geodsp1s.img.xz
>   /usr/lib/syslinux/diag/geodspms.img.xz
> I guess one would have to pull them out of the package available at
>   https://packages.debian.org/wheezy/all/syslinux-common/download
> 
> Is there an official SYSLINUX URL where to get the images ?
> 
> 
> > As I mentioned before, there is also "isolinux-debug.bin",
but it is
> > not supported by isohybrid, AFAIK.
> 
> The problem is not in the El Torito image, except the fact that its
> alleged first sector does not bear the magic number.
> Of course, "isolinux-debug.bin" is not supposed to bear the magic
number
> of an isohybrid capable El Torito image at all.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
@Thomas,

In the last few years, ISOLINUX has received very low attention, both 
upstream and downstream. So I' am about to (attempt to) provide a 
generic suggestion for you (and for interested users / developers).

At the moment I am writing this, the latest revision of the "diag/*.*"
binaries / images are only available in Syslinux 6.04-pre1. Since the 
Syslinux distribution archives contain both sources and binaries, you 
(and Debian users) should be able to download it from kernel.org and 
find these binaries in the subdirectories under the "bios/diag/" 
directory of the Syslinux official archive.

What I would suggest would be to have a simple, very small minimal set 
of ISO images, which should complement - not to be confused with 
compliment - the aforementioned diagnostic images.

The diagnostic images should be written to a USB device using dd. There 
is no need for ISO images for that. Booting with such USB devices 
should provide part of the info.

On the other hand, having minimal ISOhybrid images, each one containing 
different versions of ISOLINUX, would allow a similar test for users: 
dd the ISOhybrid image to USB and see how it boots.

These "testing" isohybrid images don't even need kernels, initrd
nor
anything else (not even syslinux.cfg). They should only contain the 
bootloader files and the corresponding c32 files, perhaps with the 
additional binaries and scripts already included in the Syslinux 
distribution archives.

Having floppy-emulation ISO images could be part of the set.

These "testing" isohybrid images should not contain multiple catalog 
entries. They should either have one ISOLINUX version, or one EFI 
bootloader for one platform, and so on. KISS.

Each isohybrid image would correspond to a different version of 
Syslinux files.

The only objective of these images is to get to the boot prompt. In the 
case of the isohybrid images, the user could execute some of the c32 
modules from the boot prompt, in order to obtain additional information 
(e.g. disk.c32, meminfo.c32, and so on).

So, for example, if David (who started this long discussion) would want 
to know whether an older version of ISOLINUX would be able to at least 
boot his older systems, he just needs the small minimal images. The 
point is that he would not need to learn how to build isohybrid images 
just for these purpose.

Now, besides this whole discussion and with no reference to anyone in 
particular nor offense intended, I have to admit that I am a little bit 
tired of answering questions related to how an ISO image either fails 
or succeeds when booting from USB (we both have been part of these 
discussions during the last few years) . I am very much aware that 
maintainers of Linux distributions want to keep distributing _only_ ISO 
images and they want to support _only_ the "simple" dd method, in
spite
of the fact that for the most part optical media is not being used for 
these purposes anymore. At the same time that distro maintainers want 
to "simplify" their workload, The Syslinux Project keeps ignoring the 
matter. Although these words could be interpreted in a negative manner 
(not my intention), the point is about actual positive effects: let's 
try to provide some kind of simple path to move forward, considering 
that distro maintainers and Syslinux' developers won't.

Having simple minimal boot images won't solve all the problems 
(especially those related to building environment), but perhaps they 
can help users and support (at least a little bit?). After all, they 
only have to dd images and test the boot. If nothing else, they would 
serve for comparison, narrowing down the source of problems.

At any rate, I am still of the opinion that using "the flexible way" 
and/or auxiliary tools should be _much_ more effective and less 
time-consuming for troubleshooting.

Regards,
Ady.