[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

Thomas Schmitt scdbackup at gmx.net
Fri Mar 24 02:32:29 PDT 2017


Hi,

C/H/S addressing and reading of first block seems to be ok in isohdpfd.bin.

The main suspect for the failure of the attempt with isohdpfd.bin is the
number or content of the blocks read after the first one.

But i have no clue why isohdpfc.bin should do better than isohdpfd.bin.
They differ just by one instruction (JC = 0x72 versus JMP = 0xEB) which
both are performed before the reading and should actually be equivalent on
David's BIOS.


MartinS wrote:
> Looking at the code I see there might be a difference in CX _if_ the
> EBIOS check call succeeds but doesn't return correct value in BX.

Can this cause a failure to read the further 79 blocks from isolinux.bin ?


------------------------------------------------------------------
Reasoning:

David Christensen wrote:
> Trying isohdpfd.bin:
> attached picture IMG_1578-r.JPG:

The data block shown is the correct start block of isolinux.bin.

Whatever happened next, it is not due to failure to address the
right block.
(I did not compare byte by byte. But two start lines , two end lines,
 and magic number FBC07870 match.)


> ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry...

This error message stems from isolinux.bin, not from the MBR.
So we really ended up in the running boot image program.

The checksum is tested with all isolinux.bin starts. From CD too.
It belongs to the Boot Info Table feature inside isolinux.bin
(see "man mkisofs" or libisofs-*/doc/boot_sectors.txt):

Byte Range | Value      | Meaning
---------- | ---------- | ----------------------------------------------------
   8 -  11 |    pvd_lba | Block address of the Primary Volume Descriptor.
           |            | This is the session start LBA + 16.
           |            |
  12 -  15 |   file_lba | Block address of the start of the boot image file
           |            | content. Block size is 2048.
           |            |
  16 -  19 |   file_len | Number of bytes in boot image file content.
           |            |
  20 -  23 |   checksum | The sum of all 32-bit words of the file content
           |            | from byte 64 to file end.
           |            |
  24 -  63 |          0 | Reserved
---------- | ---------- | ----------------------------------------------------
All numbers are stored little-endian.

In the shown data (and in isolinux.bin hexdump):
  pvd_lba    = 10 00 00 00 = 0x10   =    16
  file_lba   = 3F 08 00 00 = 0x83f  =  2111 = 8444 / 4
  file_len   = 00 A0 00 00 = 0xa000 = 40960

I can confirm that these table entrys are correct for this ISO.
In question is only:

  checksum   = 31 2C D2 93

The boot info table was written by xorriso. The boot success with many
systems tells us that the checksum is ok in normal situations.

"-ls -l" and field "file_len" both say that in total 80 blocks should
be read by the MBR.

----------

The riddle of the all zero first block is now explainable:

The address conversion
  8444 -> 1/6/3
matches two geometries:
  H/C= 128  S/H= 63
  H/C= 195  S/H= 42

I would assume the first one. It would yield with the MBR bug:
  8444 -> 1/2/125
which is not a valid C/H/S address under S/H=63 and thus does not have
to yield a successful read operation by the BIOS.

-----------

MartinS wrote:
> Amazingly the size of the code in isohdpfd decreased by one byte
> although it's more informative!

I still did not find the spot in the Intel manual which tells me
the bytes sizes of instructions and their operands. Yesterday i riddled
which bytes after the DIVB instruction are the stack address:
  f6  36  ee  7b
and whether to add or to subtract 2 with that address.
Finally isohdpfc.bin told me that "ee" must become "f0" to correct the bug.

(This would mean we can correct existing ISOs by this bash command

  echo -n $'\xf0' | dd conv=notrunc bs=1 seek=256 count=1 of=the.iso

)

-----------

All old riddles seem solved now.
The confusion of the two stack addresses explains the failures.

The new riddle is:
Why did isohdpfd.bin not load correctly the content of the following
79 blocks of isolinux.bin ?

Is this reproducible in multiple attempts ?

-----------

Have a nice day :)

Thomas


More information about the Syslinux mailing list