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

Hi,

Geert Stappers wrote:
> Contact David off-list, he did unsubscribe.
Can you tell when he unsubscribed (i.e. which of the messages he got
as last one) ?

> Martin posted elsewhere in this thread "Thomas, you found the
bug"
> and provided a patch.
Open question is whether the fix helps with David's BIOS.
The newest answer from Martin indicates that a failure to read should
have caused a different error message than reported by David.
But successfully reading a wrong block address should not have yielded
all zeros.

@Martin:
Can you provide a binary MBR with the bug fix and diagnostic prints ?
If we cannot get testing from David then i would be interested to keep
such an MBR for the next occasion.


Have a nice day :)

Thomas

Hi,

i posted an update report to the Debian bug and Cc'ed David:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857597#45


Have a nice day :)

Thomas

On Thu, Mar 23, 2017 at 09:58:08AM +0100, Thomas Schmitt via Syslinux
wrote:
> @Martin:
> Can you provide a binary MBR with the bug fix and diagnostic prints ?
> If we cannot get testing from David then i would be interested to keep
> such an MBR for the next occasion.
Cc:ing David.

Yes, here <http://www.ludd.ltu.se/~ams/tmp/isohdpf_dump.tgz>.

It contains isohdpfd.{S,bin,lst} and isohdpfc.{S,bin,lst}.
isohdpfd is head/sector corrected from the previous one.
isohdpfc is the same but won't even check for EBIOS (similar to
force_cbios).

For David's old machine it shouldn't matter which one he uses.


Would the syslinux project like that I add them somewhere? E. g. in
diag/mbr/? They won't stay forever at the address above.


-- 
MartinS

CC:ing syslinux.

Thanks for testing David.

On Thu, Mar 23, 2017 at 05:23:51PM -0700, David Christensen
wrote:
> Trying isohdpfd.bin:
...
> Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of
information,
> with "Key?" at the bottom (see attached picture IMG_1578-r.JPG).
> 
> 
> When I press a key, I see the following message at the bottom and the
> computer stops:
> 
> ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry...
> 
> 
> Trying isohdpfc.bin:
...
> Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of
information,
> with "Key?" at the bottom.
Is it exactly the same numbers as in the picture you attached for the
isohdpfd.bin boot?
> When I press a key, the following message flashes by at the bottom:
> 
> ISOLINUX 6.03 20150819 EHDD Copyright (C) 1994-2014 H. Peter Anvin et al
> 
> 
> The screen goes black, the PC speaker beeps, then the Debian Installer
> starts.  When I select Install, there is a delay of ~20 seconds, the screen
> goes black, then the following message flashes by at the top:
...
[Successful start of install snipped.]


What the ??!! There shouldn't be any difference.

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.

Please try this new isohdpfd.bin that indicates which part of EBIOS
detection fails:
<http://www.ludd.ltu.se/~ams/tmp/isohdpf_dump.2.tgz>

 * If an EBIOS is not detected outputs:
 * <X><LBA0>/<C0>/<H0>/<S0>
 * <LBA1>/<C1>/<H1>/<S1>
 * <LBA2>/<C2>/<H2>/<S2>
 * <LBA3>/<C3>/<H3>/<S3>
 * <Big hex dump of first loaded sector>
 * Key?
 *
 * and waits for a key press.
 * <X> is A if the EBIOS detection failed the extended disk access
 * support bit, B if the EBIOS detection failed the BX signature and
 * C if EBIOS detection failed with carry return.
   
If my theory is correct then this one will print B for <X>.

The included isohdpfc version really forces no EBIOS calls this time
as it makes sure to clear the flag.


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


-- 
MartinS

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

CC:ing syslinux

David Christensen reports that my latest isohdpfd.bin reported
C, thus it failed early (carry set) in finding an EBIOS.

My interpretation is that it must corrupt CX so isolinux is fooled into
trying EBIOS first.

So, again David, can you please try this one:
<http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz>

To keep your (our?) spirits up I've named it of you.

It won't boot anything, but it will:

 * Hacked special David version. Won't boot anything.
 *
 * Will print the result of INT 0x13, AH=0x41:
 *
 * <CARRY>
 * AX
 * BX
 * CX
 * DX
 * I die now.
 *
 * where <CARRY> is either "No carry." or "Carry."
depending of the
 * setting of the carry flag after the call.


I predict it will print:
Carry.
<something>
<something>
<0 != something>
<something>
I die now.


If it doesn't I don't know and ideas what you (Thomas mainly I
suppose) want me to code/try for you/us are accepted. (Starting to
flap my arms uselessly.)


Meanwhile Thomas found that isolinux expects the number of heads and
sectors parameters in the way that the offsets was (in isohdpfx.bin),
not the pushes, so I've made another more correct corrected
isohdpfx.bin here:

<http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324>

Please try that one too. It should work if my prediction above is
right.


Thanks.


-- 
MartinS

Hi,

for some reason David always omits the Cc: to this list.

He has now reported to Martin and me the outcome of the latest two MBR
test proposals.

- His BIOS announces no LBA addressing but another extra feature.
  This lead to unexpected success in one of David's tests.

- The newest fix proposal by Martin is a full success !

  Distros which produce isohybrid should consider to already now offer
  it for download in case the ISO fails to boot from stick on old iron:
    http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324
  The source patch is at the second half of
    http://www.syslinux.org/archives/2017-March/025706.html


---------------------------------------------------------------------
Details:

Martin Str|mberg wrote:
> > > <http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz>
> > > * <CARRY>
> > > * AX
> > > * BX
> > > * CX
> > > * DX
> > > * I die now.
i wrote:
> > I place my bet on CX value 4. :))
David Christensen wrote:
> No carry.
> 3000
> AA55
> 0004
> 0080
> I die now
Hah ! CX announces no LBA addressing but Enhanced Disk Drive Support.
 
https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present

So isohdpfc pushed CX = 4 onto the stack, because it skipped
    andw 1,%xc
So isolinux.bin read in "EHDD" mode by LBA and succeeded although it
did not announce this capability.

isohdpfd reached the "andw" instruction. So CX was set to (1 & 4)
= 0
before it got pushed. So isolinux.bin read in "CHDD" mode by C/H/S and
thus ran into the stack sequence bug.


Martin:
> > > http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324
David:
> the following flashes by near the top:
> ISOLINUX 6.03 20150819 CHDD Copyright (C) 1994-2014 H. Peter Anvin et al
Here we have C/H/S addressing in isolinux.bin, as expected.
I understand that loading and verifying the whole isolinux.bin has
already succeeded when the copyright message appears.


David:
> Then the Debian Installer runs. I choose "Install", there is
delay of ~20
> seconds and then the next screen comes up.  Everything tests normally
> through the partitioning screen (when I stop testing)
Jubel ! \o/

No further obstacles on the way to a running Linux.

We can conclude that the BIOS is not mad but just overly modest.
It does not brag with its ability to use INT 13 AH 42 for LBA
addressing.

> It would be nice if the patch made it into Debian 8.8.
I will report at the Debian bug.

I am not sure whether we can convince Steve McIntyre to put a newly
created MBR into the installation ISOs by default. But at least the
fixed MBR should be offered for download and local application.
The necessary dd command is very similar to the one which one already
needs to put the ISO on stick.


Have a nice day :)

Thomas