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

On 03/18/2017 01:18 AM, Ady Ady via Syslinux wrote:
> Some of the things you should / could (re)test / (re)try:
>
> _ Verify the md5sum of the ISO image.
SHA256 verified for downloaded image and for contents of USB flash drive
(see below).

> _ Is this particular USB device _still_ capable of booting newer
> computers?
Yes.

> What happens if you would try _again_ to boot a newer computer?
It boots.

> If the error message is seen now (while it was booting OK before such
> newer systems), then it might be a sign that the USB device is now
> failing.
The USB flash drive shows no indication of failure.

> _ Before executing dd in order to write the ISO image to the USB
> deice, verify that you UNmount the filesystem volumes located in the
> USB device.
My systems do not have automount enabled.


I use this USB flash drive for bootable installer images; I do not
attempt to mount it.  I don't know that I could, even if I wanted to:

2017-03-18 13:02:01 root at cd2533 ~
# fdisk -l /dev/sdc

WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util
fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdc: 4004 MB, 4004511744 bytes
255 heads, 63 sectors/track, 486 cylinders, total 7821312 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x59f54072

    Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           0     1325055      662528    0  Empty
/dev/sdc2            8524        9131         304   ef  EFI (FAT-12/16/32)

2017-03-18 13:02:08 root at cd2533 ~
# parted /dev/sdc u s p
Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT
table.  However, it does not have a valid fake msdos partition table, as
it should.  Perhaps it was
corrupted -- possibly by a program that doesn't understand GPT partition
tables.  Or perhaps you deleted the GPT table, and are now using an
msdos partition table.  Is this a GPT
partition table?
Yes/No? no

2017-03-18 13:02:20 root at cd2533 ~
# parted /dev/sdc u s p
Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT
table.  However, it does not have a valid fake msdos partition table, as
it should.  Perhaps it was
corrupted -- possibly by a program that doesn't understand GPT partition
tables.  Or perhaps you deleted the GPT table, and are now using an
msdos partition table.  Is this a GPT
partition table?
Yes/No? yes
Error: Both the primary and backup GPT tables are corrupt.  Try making a
fresh table, and using Parted's rescue feature to recover partitions.


I assume dd will encounter a write error and exit if some file system on
the USB flash drive is mounted when I attempt to burn the ISO file to
the device (?).

> _ In the dd command, verify that you are _not_ using a partition as
> destination device but rather the whole device. For example, if the
> USB device is identified as '/dev/sdc' in your OS, then the dd
> command should _not_ include 'of=/dev/sdc1' but rather
> 'of=/dev/sdc'.
>
> _After executing the dd command, wait enough time before extracting
> the USB device. After the dd command has finished, sometimes using a
> 'sync' command is suggested before extracting the USB device.
Yes, I do those things.


I burned the ISO to the USB flash drive again and documented the
process:

2017-03-18 12:06:12 root at cd2533 ~
# dmesg | tail -n  15
[ 5659.928036] usb 1-2: new high-speed USB device number 8 using ehci_hcd
[ 5660.060872] usb 1-2: New USB device found, idVendor=0781, idProduct=5575
[ 5660.060878] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 5660.060882] usb 1-2: Product: Cruzer Glide
[ 5660.060885] usb 1-2: Manufacturer: SanDisk
[ 5660.060889] usb 1-2: SerialNumber: <redacted>
[ 5660.061955] scsi6 : usb-storage 1-2:1.0
[ 5661.067791] scsi 6:0:0:0: Direct-Access     SanDisk  Cruzer Glide
  1.26 PQ: 0 ANSI: 5
[ 5661.070450] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 5661.076526] sd 6:0:0:0: [sdc] 7821312 512-byte logical blocks: (4.00
GB/3.72 GiB)
[ 5661.084642] sd 6:0:0:0: [sdc] Write Protect is off
[ 5661.084649] sd 6:0:0:0: [sdc] Mode Sense: 43 00 00 00
[ 5661.085390] sd 6:0:0:0: [sdc] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[ 5661.115648]  sdc: unknown partition table
[ 5661.120771] sd 6:0:0:0: [sdc] Attached SCSI removable disk

2017-03-18 12:07:21 root at cd2533 ~
# time dd if=/dev/zero of=/dev/sdc bs=1M; sync
:195,dd: writing `/dev/sdc': No space left on device
3820+0 records in
3819+0 records out
4004511744 bytes (4.0 GB) copied, 911.198 s, 4.4 MB/s

real	15m11.204s
user	0m0.000s
sys	0m7.888s

2017-03-18 12:40:31 root at cd2533 ~
# cd /var/local/data/dpchrist/iso/debian/8.7.1/i386/

2017-03-18 12:40:50 root at cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# grep debian-8.7.1-i386-xfce-CD-1.iso SHA256SUMS
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde
debian-8.7.1-i386-xfce-CD-1.iso

2017-03-18 12:41:06 root at cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# ll debian-8.7.1-i386-xfce-CD-1.iso
-rw-r--r-- 1 dpchrist dpchrist 678428672 2017/03/04 17:02:57
debian-8.7.1-i386-xfce-CD-1.iso

2017-03-18 12:41:30 root at cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# sha256sum debian-8.7.1-i386-xfce-CD-1.iso
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde
debian-8.7.1-i386-xfce-CD-1.iso

2017-03-18 12:41:54 root at cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# time dd if=debian-8.7.1-i386-xfce-CD-1.iso of=/dev/sdc bs=1M; sync
647+0 records in
647+0 records out
678428672 bytes (678 MB) copied, 161.132 s, 4.2 MB/s

real	2m41.135s>

user	0m0.012s
sys	0m1.640s

2017-03-18 12:51:52 root at cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# time dd if=/dev/sdc bs=1M count=647 | sha256sum
647+0 records in
647+0 records out
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde  -
678428672 bytes (678 MB) copied, 33.1367 s, 20.5 MB/s

real	0m33.141s
user	0m5.992s
sys	0m1.948s


The result is the same -- "isolinux.bin missing or corrupt" when
booting
USB flash drive in any USB port in an older PC, but USB flash drive 
boots fine in newer PC's.

> _ In the problematic computer(s), are there several USB ports? Have
> you tried using another USB port when booting with this device (USB
> ports in the front can frequently be a suspect, but not only those)?
>
Same result for 4 rear ports and 2 front ports on old PC.

> Is the USB device connected directly to the USB port?
Yes.

> Or instead, is there some USB hub or similar device in between?
No.

> _ Which type of USB device is this? Are you using a USB flash drive,
> a HDD connected by USB, or some kind of (SD) card connected by USB?
SanDisk Cruzer Glide 4 GB (USB flash drive).

> _ With the USB device connected to (one of) the problematic
> computer(s), power up the system and get into the BIOS setup. In the
>  BIOS setup screen(s), change the boot order in such way that the USB
>  device is recognized as first boot device. Other devices such as
> CD-ROM and your local HDD should be listed after the USB device in
> the boot order (as second/third boot devices). Then save the BIOS
> settings and try booting with the USB device.
I have adjusted the boot order in BIOS setup, but it is unnecessary --
the only other drive is a CD/DVD-RW drive, and it does not contain a disc.


Furthermore, if the BIOS did not attempt to boot from the USB flash
drive, I would not see the error message "isolinux.bin missing or
corrupt".

> _ If the BIOS setup includes some "fast (POST) boot" or
"quick (POST)
>  boot" (or similar) option, disable it.
Already done.

> _ If the above changes in the BIOS setup are not enough for a
> successful boot with your USB device, then boot back into the BIOS
> setup screen(s) and change the way your USB is being detected at boot
>  time. Sometimes a USB device in a specific computer cannot boot when
> it is detected as "USB-AUTO", but it can succeed when it is
> specifically selected as "USB-HDD", or as "USB-FLOPPY",
or as
> "USB-ZIP'. This is usually selected when pressing a specific key
> during boot time and selecting a specific device type as boot device
> - the specific key (F1/F2/F12/DEL/ESC or some combination of keys)
> depends on your particular computer.
Advanced -> USB Configuration:

- USB Function -- Enable or Disable.  When disabled, the BIOS does not
boot the USB flash drive.  Therefore, this setting is, and must be, enabled.

- High-Speed USB -- Enable or Disable.  The problem is the same with
either setting.

- Legacy USB Support -- Enable or Disable.  When disabled, the BIOS does
not boot the USB flash drive.  Therefore, this setting is, and must be,
enabled.

- USB 2.0 Legacy Support -- Full-Speed or High-Speed.  The problem is
the same with either setting.

> _ Some older computers might not be able to detect "big" USB
devices
>  correctly. Using a USB flash drive of 1GB might succeed while a
> bigger one might fail. There are too many reasons for this behavior
> and thus, too many possible workarounds / solutions; trying a smaller
> USB device is just one of many.
I have 128 MB and 4 GB USB flash drives, and nothing in between.

> There are alternative ways to boot from USB devices, and they depend
> on how the ISO image was transferred onto the USB device. If you find
> that your current boot device cannot boot these old systems, then the
> "dd method" might not be a good choice for these old computers,
but
> an alternative method might work.
>
> Considering that the other USB device (the one with memtest) is
> booting correctly, you might want to describe here how exactly you
> transferred memtest to this other USB device, and what is different
> from it in comparison to the one that is having problems.
The memtest USB flash drive was created using the same method as above.


I also have a FreeBSD 11.0 i386 USB flash drive created using the same
method as above, and it boots fine in the older computers.


I need a debugging version of whatever program is generating the error
message "isolinux.bin missing or corrupt".  What binary and/or source
packages do I need to install?  What document do I need to read to
create a debugging build of this program?  What document do I need to 
read to build a hybrid ISO containing my debugging version of the program?


David

Hi,

David Christensen wrote:
> I use this USB flash drive for bootable installer images; I do not
> attempt to mount it.  I don't know that I could, even if I wanted to:
  mkdir /mnt/iso
  mount /dev/sdc /mnt/iso

or, because partition 1 starts at block 0, you may mount it too

  mount /dev/sdc1 /mnt/iso

> # fdisk -l /dev/sdc
> WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The
util
> fdisk doesn't support GPT.
That's actually a bug in fdisk. The GPT is invalid because it is not
announced by a "Protective MBR".
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdc1   *           0     1325055      662528    0  Empty
"Empty" is not a realistic statement but just a human readable
representation
of partition tye 0x0. It is unusual but needed to avoid that UEFI sees
partition 2 as nested partition inside partition 1.
> # parted /dev/sdc u s p
> Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT
> table.  However, it does not have a valid fake msdos partition table, as
> it should.
Smarter than fdisk.
> Is this a GPT partition table?
> Yes/No? yes
> Error: Both the primary and backup GPT tables are corrupt. 
That's because of the nested GPT partitions, i assume.

The complaints of parted are justified. But the deviations from GPT
specs and MBR traditions are necessary and intentional.
(The mjg BIOS+EFI+Mac isohybrid layout is king in booting. Otherwise one
 should not look at it while reading the specs.)

In any case, a non-EFI BIOS should not see anything noteworthy in
the GPT equipment. Just some bytes in some blocks of the medium.

> I assume dd will encounter a write error and exit if some file system on
> the USB flash drive is mounted when I attempt to burn the ISO file to
> the device (?).
If you have write permission then dd can overwrite the drive.
A simultaneously active read-write filesystem is likely to alter the
ISO on the drive. But you verified the SHA256. So the ISO is ok.

> I need a debugging version of whatever program is generating the error
> message "isolinux.bin missing or corrupt".
That would be the MBR code at bytes 0 to 432 of the ISO.
Source code (assembler) is at
  http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S

It's a very narrow piece of space for a program. One may re-use the
"nop" bytes at label "_start:". They serve as fake Apple
Partition Map
header block.
If the first ".byte 0x33, 0xed" before the "nop"s gets
removed then the
second one after the "nop"s needs to be removed, too.

One could hardcode the block address of "isolinux.bin" (8444 decimal)
and inspect or print the bytes read from there via BIOS INT 13H
(see https://en.wikipedia.org/wiki/INT_13H).
Next one would try on Linux to find the block iaddress which yields that
content.

Further one could try to find out whether "we have EBIOS" with LBA
addressing or "CBIOS" with Cylinder/Head/Sector addressing.
If CBIOS, INT 13 with AH 6 is used for reading, else AH 42.
If C/H/S and if the EBIOS assumes a different size of head and cylinder
than the MBR does ... that would explain a mislead read attempt.
But i understand that INT 13 with AH 8 is used to inquire the C/H/S
factors from the BIOS in line 176 ff. So if the BIOS does not lie then
the computation at label "read_sector_cbios:" should be correct.

Regrettably i still have 4560 pages of the Intel processor manual to read
before i can start to handcode an MBR. ~:o)


Have a nice day :)

Thomas

> On 03/18/2017 01:18 AM, Ady Ady via Syslinux wrote:
> > Some of the things you should / could (re)test / (re)try:
> >
> > _ Verify the md5sum of the ISO image.
> 
> SHA256 verified for downloaded image and for contents of USB flash drive
> (see below).
> 
> 
> > _ Is this particular USB device _still_ capable of booting newer
> > computers?
> 
> Yes.
> 
> 
> > What happens if you would try _again_ to boot a newer computer?
> 
> It boots.
> 
> 
> > If the error message is seen now (while it was booting OK before such
> > newer systems), then it might be a sign that the USB device is now
> > failing.
> 
> The USB flash drive shows no indication of failure.
 
 
In some cases, failure to boot is a sign of failure in the USB device.
 
 
> 
> 
> > _ Before executing dd in order to write the ISO image to the USB
> > deice, verify that you UNmount the filesystem volumes located in the
> > USB device.
> 
> My systems do not have automount enabled.
> 
> 
> I use this USB flash drive for bootable installer images; I do not
> attempt to mount it.  I don't know that I could, even if I wanted to:
> 
 
 
 (snip)
 
> 
> I assume dd will encounter a write error and exit if some file system on
> the USB flash drive is mounted when I attempt to burn the ISO file to
> the device (?).
 

Not necessarily. Might, or might not.


 (snip)
 
 
> 
> 
> > _ With the USB device connected to (one of) the problematic
> > computer(s), power up the system and get into the BIOS setup. In the
> >  BIOS setup screen(s), change the boot order in such way that the USB
> >  device is recognized as first boot device. Other devices such as
> > CD-ROM and your local HDD should be listed after the USB device in
> > the boot order (as second/third boot devices). Then save the BIOS
> > settings and try booting with the USB device.
> 
> I have adjusted the boot order in BIOS setup, but it is unnecessary --
> the only other drive is a CD/DVD-RW drive, and it does not contain a disc.
> 
 
 
You probably mean in addition to a HDD, right?


> 
> Furthermore, if the BIOS did not attempt to boot from the USB flash
> drive, I would not see the error message "isolinux.bin missing or
corrupt".
> 
 
 
This is part of the troubleshooting steps, and there are valid reasons 
for the suggestion / request. BIOS implementations are not always 
"perfect". For instance, one USB-AUTO device might boot in one system 
and not in another, and by changing (or imposing) the way it is 
recognized, the result / behavior might change (e.g. "USB-HDD", device
0x80 vs. 0x81 and so on).
 
 
> 
> > _ If the BIOS setup includes some "fast (POST) boot" or
"quick (POST)
> >  boot" (or similar) option, disable it.
> 
> Already done.
> 
> 
> > _ If the above changes in the BIOS setup are not enough for a
> > successful boot with your USB device, then boot back into the BIOS
> > setup screen(s) and change the way your USB is being detected at boot
> >  time. Sometimes a USB device in a specific computer cannot boot when
> > it is detected as "USB-AUTO", but it can succeed when it is
> > specifically selected as "USB-HDD", or as
"USB-FLOPPY", or as
> > "USB-ZIP'. This is usually selected when pressing a specific
key
> > during boot time and selecting a specific device type as boot device
> > - the specific key (F1/F2/F12/DEL/ESC or some combination of keys)
> > depends on your particular computer.
> 
> Advanced -> USB Configuration:
> 
> - USB Function -- Enable or Disable.  When disabled, the BIOS does not
> boot the USB flash drive.  Therefore, this setting is, and must be,
enabled.
> 
> - High-Speed USB -- Enable or Disable.  The problem is the same with
> either setting.
> 
> - Legacy USB Support -- Enable or Disable.  When disabled, the BIOS does
> not boot the USB flash drive.  Therefore, this setting is, and must be,
> enabled.
> 
> - USB 2.0 Legacy Support -- Full-Speed or High-Speed.  The problem is
> the same with either setting.
> 
 
 
What exactly was "done"? Which USB modes this BIOS supports? USB-AUTO?
USB-HDD?...

A hunch: somehow, the CHS values for isohybrid are starting to sound as 
an issue in this case.
 
 
> 
> > _ Some older computers might not be able to detect "big" USB
devices
> >  correctly. Using a USB flash drive of 1GB might succeed while a
> > bigger one might fail. There are too many reasons for this behavior
> > and thus, too many possible workarounds / solutions; trying a smaller
> > USB device is just one of many.
> 
> I have 128 MB and 4 GB USB flash drives, and nothing in between.
> 
> 
> > There are alternative ways to boot from USB devices, and they depend
> > on how the ISO image was transferred onto the USB device. If you find
> > that your current boot device cannot boot these old systems, then the
> > "dd method" might not be a good choice for these old
computers, but
> > an alternative method might work.
> >
> > Considering that the other USB device (the one with memtest) is
> > booting correctly, you might want to describe here how exactly you
> > transferred memtest to this other USB device, and what is different
> > from it in comparison to the one that is having problems.
> 
> The memtest USB flash drive was created using the same method as above.
> 
> 
> I also have a FreeBSD 11.0 i386 USB flash drive created using the same
> method as above, and it boots fine in the older computers.
> 
 
 
This kind of diverse behavior is somewhat similar to the way different 
BIOS implementations are (or were) capable (or not) of booting optical 
media: some are capable of using El Torito no-emulation with no 
problems, while some might need a floppy-emulation mode.

Back on topic, there are too many reasons for these systems to fail 
with this Debian ISO image. For example, some BIOS implementations 
don't "like" when the bootloader file, "isolinux.bin",
is bigger than
32KiB. Others don't like when the bootloader file is located on LBA 
values over a certain limit. Incidentally, Debian 8.7 is using ISOLINUX 
6.03+, which happens to be bigger than 32KiB, whereas isolinux.bin 
version 4.xx was much smaller than 32KiB.

We could even mention partition alignment issues in a BIOS from 2003 
(63 sectors offset for the first partition vs. 2048) and appropriate 
CHS values in the isohybrid command. The potential list of 
incompatibilities and troubleshooting is not short. Whether the 
incompatibilities are a matter of reason or a capricious BIOS' 
developer, we probably won't ever know.

If I were to recommend a solution for your case, I would _not_ be 
choosing to rebuild the ISOhybrid image in a different way. Instead, 
either I would simply use optical media, or I would be partitioning and 
formatting the USB device (these are _not_ complete detailed 
instructions):

_ MBR (aka "msdos" partition) scheme
_ create one partition
_ set the partition as "bootable" (aka "active" flag)
_ dd mbr.bin
_ mount the partition; format it as FAT32
_ copy the _content_ of the ISO image to the FAT32 partition
_ install SYSLINUX on the FAT32 partition (and replace .c32 modules 
with a matching version, if needed)

Beware: I am not describing each step in detail, but some details are 
very important for the success (or not) of the procedure. Someone else 
might want to write detail step-by-step instructions.

Booting with SYSLINUX (instead of dd'ing the ISO image) should avoid 
the limitations / incompatibilities between the BIOS, ISOLINUX (6.03) 
and ISOhybrid.

There might be some additional steps needed, such as renaming the 
"isolinux" directory to "syslinux" and editing
"isolinux.cfg" (et. al.)
in a similar way. Such steps vary, depending on the content of each ISO 
image.

There are several auxiliary tools available for Linux and/or Windows 
that are capable of performing at least part of the steps, if not all 
of them.

As you can see, inserting optical media and booting from it is simpler, 
especially when the alternative is for the user to learn the details of 
the procedure, just for 2 computers.

Other participants of the Syslinux Mailing List might suggest other 
alternatives, or might have experience with auxiliary tools (there are 
many) and would recommend a specific one (in which case, posting the 
specific OS(s) in which you (can) perform the procedure is very 
relevant). Under Windows, I would suggest RUFUS for this case.
 
 
> 
> I need a debugging version of whatever program is generating the error
> message "isolinux.bin missing or corrupt".  What binary and/or
source
> packages do I need to install?  What document do I need to read to
> create a debugging build of this program?  What document do I need to 
> read to build a hybrid ISO containing my debugging version of the program?
> 
 
 
Isohybrid does not support "isolinux-debug.bin".
 
 
> 
> David
> 
 
 
Regards,
Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

On 03/18/2017 04:15 PM, Ady Ady via Syslinux wrote:
>
>> On 03/18/2017 01:18 AM, Ady Ady via Syslinux wrote:
>>> _ With the USB device connected to (one of) the problematic
>>> computer(s), power up the system and get into the BIOS setup. In
>>> the BIOS setup screen(s), change the boot order in such way that
>>> the USB device is recognized as first boot device. Other devices
>>> such as CD-ROM and your local HDD should be listed after the USB
>>> device in the boot order (as second/third boot devices). Then
>>> save the BIOS settings and try booting with the USB device.
>>
>> I have adjusted the boot order in BIOS setup, but it is unnecessary
>> -- the only other drive is a CD/DVD-RW drive, and it does not
>> contain a disc.
>
> You probably mean in addition to a HDD, right?
The computer has a HDD mobile rack.  I removed the HDD when testing the
Debian installer image on a USB flash drive.  So, the only drive other
than the USB flash drive under test was the optical drive.

>>> _ If the BIOS setup includes some "fast (POST) boot" or
"quick
>>> (POST) boot" (or similar) option, disable it.
>>
>> Already done.
...
> What exactly was "done"?
BIOS SETUP UTILITY -> Boot:

- Silent Boot is Disabled

- Intel(R) Rapid BIOS Boot is Disabled

> Which USB modes this BIOS supports? USB-AUTO? USB-HDD?...
Please see previous post for USB settings.  That's all that is available
-- there is no "USB-AUTO", "USB-HDD", etc..


David

On 03/18/2017 03:02 PM, Thomas Schmitt via Syslinux
wrote:
> Hi,
>
> David Christensen wrote:
>> I use this USB flash drive for bootable installer images; I do not
>> attempt to mount it.  I don't know that I could, even if I wanted
to:
>
>   mkdir /mnt/iso
>   mount /dev/sdc /mnt/iso
>
> or, because partition 1 starts at block 0, you may mount it too
>
>   mount /dev/sdc1 /mnt/iso
Or, using a loop device and the *.iso file:

2017-03-18 17:31:22 root at cd2533 ~
# mkdir /mnt/iso

2017-03-18 17:48:16 root at cd2533 ~
# losetup -d /dev/loop0

2017-03-18 17:51:32 root at cd2533 ~
# losetup -r -f 
/var/local/data/dpchrist/iso/debian/8.7.1/i386/debian-8.7.1-i386-xfce-CD-1.iso

2017-03-18 17:52:13 root at cd2533 ~
# losetup -a
/dev/loop0: [fe02]:126616474 
(/var/local/data/dpchrist/iso/debian/8.7.1/i386/debian-8.7.1-i386-xfce-CD-1.iso)

2017-03-18 17:52:48 root at cd2533 ~
# mount /dev/loop0 /mnt/iso
mount: block device /dev/loop0 is write-protected, mounting read-only

2017-03-18 17:53:50 root at cd2533 ~
# mount | grep loop0
/dev/loop0 on /mnt/iso type iso9660 (ro,relatime)

2017-03-18 17:53:53 root at cd2533 ~
# ll /mnt/iso
total 1152
dr-xr-xr-x 1 root root   4096 2017/01/16 02:11:29 ./
drwxr-xr-x 7 root root   4096 2017/03/18 17:31:46 ../
dr-xr-xr-x 1 root root   2048 2017/01/16 02:11:29 .disk/
-r--r--r-- 1 root root   9473 2017/01/16 02:11:29 README.html
-r--r--r-- 1 root root 190914 2017/01/14 05:52:20 README.mirrors.html
-r--r--r-- 1 root root 103482 2017/01/14 05:52:20 README.mirrors.txt
-r--r--r-- 1 root root    461 2017/01/16 02:09:49 README.source
-r--r--r-- 1 root root   6001 2017/01/16 02:11:29 README.txt
-r--r--r-- 1 root root    146 2017/01/16 02:09:47 autorun.inf
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:49 boot/
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:47 css/
lr-xr-xr-x 1 root root      1 2017/01/16 02:09:45 debian -> ./
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:47 dists/
dr-xr-xr-x 1 root root   4096 2017/01/16 02:09:46 doc/
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:49 efi/
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:59 firmware/
-r--r--r-- 1 root root 180335 2017/01/10 13:19:04 g2ldr
-r--r--r-- 1 root root   8192 2017/01/10 13:19:04 g2ldr.mbr
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:45 install/
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:49 install.386/
dr-xr-xr-x 1 root root   4096 2017/01/16 02:09:49 isolinux/
-r--r--r-- 1 root root 268674 2017/01/16 02:11:29 md5sum.txt
dr-xr-xr-x 1 root root   4096 2017/01/16 02:09:47 pics/
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:50 pool/
-r--r--r-- 1 root root 368480 2017/01/10 13:19:04 setup.exe
dr-xr-xr-x 1 root root   2048 2017/01/16 02:09:47 tools/
-r--r--r-- 1 root root    228 2017/01/16 02:09:47 win32-loader.ini

>> I need a debugging version of whatever program is generating the error
>> message "isolinux.bin missing or corrupt".
>
> That would be the MBR code at bytes 0 to 432 of the ISO.
> Source code (assembler) is at
>   http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S
I see the source code for the error message:

bad_signature:
	call	error
	.ascii	"isolinux.bin missing or corrupt.\r\n"


And the machine code:

2017-03-18 18:06:56 root at cd2533 ~
# dd 
if=/var/local/data/dpchrist/iso/debian/8.7.1/i386/debian-8.7.1-i386-xfce-CD-1.iso
bs=1 skip=177 count=37 2>/dev/null | hexdump -C
00000000  e8 83 00 69 73 6f 6c 69  6e 75 78 2e 62 69 6e 20 
|...isolinux.bin |
00000010  6d 69 73 73 69 6e 67 20  6f 72 20 63 6f 72 72 75  |missing or 
corru|
00000020  70 74 2e 0d 0a                                    |pt...|
00000025


It looks like the call to "error" (line 276) is made if a summation of
the bytes in the first four sectors of a partition don't add up to 
HYBRID_MAGIC (?).

> It's a very narrow piece of space for a program. One may re-use the
> "nop" bytes at label "_start:". They serve as fake
Apple Partition Map
> header block.
> If the first ".byte 0x33, 0xed" before the "nop"s gets
removed then the
> second one after the "nop"s needs to be removed, too.
>
> One could hardcode the block address of "isolinux.bin" (8444
decimal)
> and inspect or print the bytes read from there via BIOS INT 13H
> (see https://en.wikipedia.org/wiki/INT_13H).
> Next one would try on Linux to find the block iaddress which yields that
> content.
>
> Further one could try to find out whether "we have EBIOS" with
LBA
> addressing or "CBIOS" with Cylinder/Head/Sector addressing.
> If CBIOS, INT 13 with AH 6 is used for reading, else AH 42.
> If C/H/S and if the EBIOS assumes a different size of head and cylinder
> than the MBR does ... that would explain a mislead read attempt.
> But i understand that INT 13 with AH 8 is used to inquire the C/H/S
> factors from the BIOS in line 176 ff. So if the BIOS does not lie then
> the computation at label "read_sector_cbios:" should be correct.
>
> Regrettably i still have 4560 pages of the Intel processor manual to read
> before i can start to handcode an MBR. ~:o)
There is the processor, and then there is the system (chipset, BIOS) in 
which the processor resides.


Figuring out why debian-8.7.1-i386-xfce-CD-1.iso works on CD, but 
doesn't work on USB, in my D8765GBFLK systems would require more effort 
that I am interested in expending.


Hundreds of millions of 32-bit Intel Pentium 4-class and higher 
computers have been manufactured since 2000, many of which still work 
and could be put to use.


debian-8.7.1-i386-xfce-CD-1.iso is really a 32-bit live Linux image with 
just a few applications -- rescue shell, installer, etc..  I'd like to 
create my own custom live Linux images with the applications of my 
choosing for computers such as the above.  USB images are of more 
interest to me than CD images, because optical drives wear out in older 
computers and many newer computers omit optical drives.


Is there a way I can build live 32-bit Debian GNU/Linux USB images 
without isohdpfx.S and syslinux.bin?


Is there another 32-bit GNU/Linux distribution that is better suited to 
my purpose?


David