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

Hi,

given the fact that the conversion has the factor HC*SH = "secpercyl",
which is invariant under swapping, there remains as suspect in
read_sector_cbios only this division:

  	divb	(sectors)

There is a suspicious discrepancy in the code:

  heads		= (stack-16)
  sectors	= (stack-18)

  ...
	/* here we computer CHS values or just do some dummy computation for EBIOS */
	andw	$0x3f, %cx	/* Sector count */
	popw	%bx		/* EBIOS flag */
	pushw	%cx		/* -16: Save sectors on the stack */
	movzbw	%dh, %ax	/* dh = max head */
	incw	%ax		/* From 0-based max to count */
	pushw	%ax		/* -18: Save heads on the stack */
	mulw	%cx		/* Heads*sectors -> sectors per cylinder */

Does "-16: Save sectors on the stack" contradict "sectors =
(stack-18)" ?


Have a nice day :)

Thomas

Hi,

comparing mbr/mbr.S with mbr/isohdpfx.S i get the impression that
really the sequence of

  heads		= (stack-16)
  sectors	= (stack-18)

in isohdpfx.S is wrong.

mbr.s has

  sectors	= (stack-8)
  secpercyl	= (stack-12)

and pushes them on the stack in the same sequence: first sectors,
then secpercyl.

isohdpfx.S pushes first the sectors and then the heads, which is the
reverse sequence as its stack address definitions.


Have a nice day :)

Thomas

On Wed, Mar 22, 2017 at 12:06:12PM +0100, Thomas Schmitt via Syslinux
wrote:
> There is a suspicious discrepancy in the code:
> 
>   heads		= (stack-16)
>   sectors	= (stack-18)
> 
>   ...
> 	/* here we computer CHS values or just do some dummy computation for EBIOS
*/
> 	andw	$0x3f, %cx	/* Sector count */
> 	popw	%bx		/* EBIOS flag */
> 	pushw	%cx		/* -16: Save sectors on the stack */
> 	movzbw	%dh, %ax	/* dh = max head */
> 	incw	%ax		/* From 0-based max to count */
> 	pushw	%ax		/* -18: Save heads on the stack */
> 	mulw	%cx		/* Heads*sectors -> sectors per cylinder */
> 
> Does "-16: Save sectors on the stack" contradict "sectors =
(stack-18)" ?
Yes.

Congratulations Thomas, you've found the bug! Very well done. Thank you.

Changing the code to
sectors     = (stack-16)
heads       = (stack-18)

lets my always fail EBIOS detection version to boot the iso.

Please David if you see this, try this.


Patch:
diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S
index 6d8ab36..5a8b267 100644
--- 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)
 

-- 
MartinS

Hi,

MartinS wrote:
> Congratulations Thomas, you've found the bug!
I will for now only take credits for "one bug".
Whether it's "the bug" is still questionable, because David
reported
a read result of all zeros.

The found error cannot cause that block content is read from after the
end of the block_seq image. The error does not spoil the C component and
LBA 8444 is much more than a maximum cylinder size of 8 MiB away from
the end of the 647 MiB image.

If the H/C and S/H values were the same as with quemu's BIOS, then there
would be no reason for the BIOS to refuse reading. (Does isohdpfx.bin any
test for read error other than the magic number test of the read result ?)

But with a different geometry it is possible that the S component of the
wrong C/H/S becomes larger than the true S/H parameter. This would be an
illegal address and would justify failure to read.

> Please David if you see this, try this.
Yes. Pullease. :))

If it is the decisive trick, then patching it onto the start of the
original ISO on stick should make that ISO 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


Have a nice day :)

Thomas