Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

intermediate report:

We found a bug in isohdpfx.bin which spoils the C/H/S address conversion
for BIOSes which do not support LBA addressing.
  http://www.syslinux.org/archives/2017-March/025692.html

It turned out that David Christensen's BIOS does not support INT 13 AH 41
which causes isohdpfx.bin to use C/H/S addressing.
If one forces this C/H/S addressing on qemu-system-i386, then the MBR
reads the wrong blocks because it confuses heads-per-cylinder and
sectors-per-head.

Martin Str|mberg posted a patch:
-----------------------------------------------------------------------
--- a/mbr/isohdpfx.S
+++ b/mbr/isohdpfx.S
@@ -48,8 +48,8 @@ isolinux_start_hybrid		= 0x7c00+64+4
 stack		= 0x7c00
 partoffset	= (stack-8)
 driveno		= (stack-14)
-heads		= (stack-16)
-sectors		= (stack-18)
+sectors		= (stack-16)
+heads		= (stack-18)
 ebios_flag	= (stack-20)
 secpercyl	= (stack-24)
-----------------------------------------------------------------------
which with his qemu BIOS repairs C/H/S addressing.

Regrettably this patch did not reach David Christensen, because he
unsubscribed at syslinux@zytor.com before the bug was found.

It is not sure whether this really fixes the problem with David's BIOS
because other than qemu's BIOS it did not read a wrong block content
out of the test image but rather a block with all zeros.
(The test image has its blocks filled with their address number. All
 zero is not among them, because at block 0 sits the MBR.)

I am Cc-ing David with this mail in the hope that he will test the
patch and report its outcome.

-------------------------------------------------------------------
David:

If it is the decisive trick, then patching the fixed MBR into the
first 432 bytes of the ISO should make it bootable.

If it is patched onto the start of the block_seq image on stick, then
it should report block content that is not all zero, but rather
  00 00 20 FC ... 00 00 20 FC

If it does not solve the problem, then i would be interested in learning
which block content is read after the patch. I.e. in this case please
try again with Martin's diagnostic MBR with the patch applied and let
me know the diagnostic output.


Have a nice day :)

Thomas