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

On Tue, Mar 21, 2017 at 09:03:35AM +0100, Thomas Schmitt via Syslinux
wrote:
> I think we should offer David a binary which he can combine with
> the MBR of the ISO and the image with the recognizable blocks.
> I will later today upload a binary version of my block producer
> and post the URL.
> 
> The combination will be:
>   432 bytes from Martin's MBR
>    80 bytes from the Debian ISO with isolinux block address
>   647 MiB from my block producer
> 
> --------------------------------------------------------------------
> Looking at the assembler code:
> 
> What's the meaning of
>         call    print_string
>         .ascii  "Key?\r\n"
It's waiting for a key because the debian iso displays some graphics
stuff so you won't have time to see any of the debug printing.
> How large is the binary currently ?
> Would there be room to print the (Cylinder, Head, Sector) address in
> case of CBIOS ?
Yes. It becoming very tight now, so I shortened the error messages.


First though I want to say I've managed to simulate David's error in
qemu by forcing isohdpfx.bin to fail the EBIOS test.

        /* Check to see if we have EBIOS */
        pushw   %dx             /* drive number */
        movb    $0x41, %ah      /* %al == 0 already */
        movw    $0x55aa, %bx
        xorw    %cx, %cx
        xorb    %dh, %dh
        stc
        int
        $0x13
//XXX   jc      1f
        jnc     1f
        cmpw    $0xaa55, %bx
        jne     1f
        andw    $1,%cx        /* Bit 0 = fixed disk subset */
        jz      1f

With that jc changed to jnc you will invert the result of the EBIOS
test and my qemu always has EBIOS.

Download the resulting isohdpfx here:
<http://www.ludd.ltu.se/~ams/tmp/isohdpfx.force_cbios.bin> 


Back to Thomas' debug prints.

You can download my logger version of isohdpfx called isohdpfd here:
<http://www.ludd.ltu.se/~ams/tmp/isohdpfd.bin>
<http://www.ludd.ltu.se/~ams/tmp/isohdpfd.S>

In the EBIOS case it will print:

E<LBA0>/<LBA1>/<LBA2>/<LBA3>/
<Big dump of first loaded sector>
Key?

and wait for a key press.

In the CBIOS case it will print

C<LBA0>/<C0>/<H0>/<S0>
<LBA1>/<C1>/<H1>/<S1>
<LBA2>/<C2>/<H2>/<S2>
<LBA3>/<C3>/<H3>/<S3>

<Big dump of first loaded sector>
Key?

and wait for a key press.


-- 
MartinS

Hi,

MartinS wrote:
> I want to say I've managed to simulate David's error in
> qemu by forcing isohdpfx.bin to fail the EBIOS test.
Wow. This could mean that the C/H/S related code is generally unsuitable
for the job.

> C<LBA0>/<C0>/<H0>/<S0>
> <LBA1>/<C1>/<H1>/<S1>
> <LBA2>/<C2>/<H2>/<S2>
> <LBA3>/<C3>/<H3>/<S3>
Anything strange to see with this sequence of addresses which are
supposed to be consequtive ?

Whatever, if this was only about confused addresses, then David would
probably see one of the blocks with numbered content.
The all-0 read result looks rather like there had been no reading
at all.

It will be interesting to hear from David whether a non-zero block
is read when he fills the USB stick up to the end.


Have a nice day :)

Thomas

> Hi,
> 
> MartinS wrote:
> > I want to say I've managed to simulate David's error in
> > qemu by forcing isohdpfx.bin to fail the EBIOS test.
> 
> Wow. This could mean that the C/H/S related code is generally unsuitable
> for the job.
> 
 
As I mentioned in the other email thread (I don't know whether readers 
are following both threads or just this one), this is why I suggested 
to use the diag/*.img before. That's the reason they were created, no 
need to combine anything, no need to build anything.

And these 2 email threads are a case in point: use SYSLINUX as soon as 
isohybrid fails.

I have suggested (in the other email thread) 3 _simple_ tests. I hope 
we get the feedback.

Regarding having some debug/diagnose variant of the isohybrid MBR, IMHO 
we should simply start a new "clean" thread and use qemu for testing
it
(now that Martin was able to replicate the issue). If David is kind 
enough to test that one too, excellent. And if all this ends up in a 
new alternative "diag" MBR that can be included in the official code, 
even better.

@Thomas, please remember that the isohybrid tool is supposed to have 
(C)HS parameters but that most distro maintainers don't care to use 
them. For an ISO image smaller than 1GiB, the recommended (C)HS values 
(in order to obtain max compatibility) are not the same that are 
recommended for a bigger image. And here we have a "small" ISO image 
with a "medium" sized USB device, so we should not be surprised to see
some BIOS implementations being confused and thus failing to boot.

> 
> > C<LBA0>/<C0>/<H0>/<S0>
> > <LBA1>/<C1>/<H1>/<S1>
> > <LBA2>/<C2>/<H2>/<S2>
> > <LBA3>/<C3>/<H3>/<S3>
> 
> Anything strange to see with this sequence of addresses which are
> supposed to be consequtive ?
> 
> Whatever, if this was only about confused addresses, then David would
> probably see one of the blocks with numbered content.
> The all-0 read result looks rather like there had been no reading
> at all.
> 
> It will be interesting to hear from David whether a non-zero block
> is read when he fills the USB stick up to the end.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
 
Regards,
Ady.

> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

Hi,

funny or enlightening observation:

With my qemu-system-i386 it would work if the detected Heads/Cylinder and
Sectors/Head factors would change positions !

The effective read operation seems to use H/C = 32 , S/H = 63.
The correct LBA would be addressed by     H/C = 63 , S/H = 32.

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

I have transplanted the "Force CBIOS" change from
isohdpfx.force_cbios.bin
to isohdpfd.bin.
The Intel manual tells me that JNC is 0x73 (= 's') and JC is 0x72
('r').
Looking for the instruction operand 0xaa55 in isohdpfd.bin leads me to
the value 0x72 at byte position 56.

So i patched isohdpfd.bin to let it force CBIOS by

  cp isohdpfd.bin isohdpfd.force_cbios.bin
  echo -n s | dd conv=notrunc bs=1 count=1 seek=56 of=isohdpfd.force_cbios.bin

composed the proposed diagnostic ISO and ran

  qemu-system-i386 -m 512 -hda bseq_isohybrid.iso

My frankensteining obviously worked.
The result is:

  C00...0020FC/0004/0B/1D
  00...0020FD/0004/0B/1E
  00...0020FE/0004/0B/1F
  00...0020FF/0004/0B/20

  00002251...00002251
  ...
  00002251...00002251

The block content 0x20FE tells that the decimal address is 8785 whereas
the requested address was 8444.

So here we clearly have a wrong translation from LBA to C/H/S.

But the result differs from what David reports. My run did read a
block although it was the wrong one.


I have a guesser function for disk geometry in libisofs. It says that

  HC= 32 , SH= 63

is the only valid combination where 

  HC * SH * 4 + SH * 11 + 29 - 1 = 8785

(The function works by brute force, simply trying all combinations of
 {1...255} x {1 ... 63}. Often it finds more than one solution.)

The only solution for 8444 = (4,11,29) is just the swapped solution
of the effective read address:

  HC = 63 , SH = 32

  HC * SH * 4 + SH * 11 + 29 - 1 = 8444


Have a nice day :)

Thomas