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

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

Hi,

correction of a copy+paste error:

I wrote:
> The block content 0x20FE tells that the decimal address is 8785
It should have been:

  The block content 0x2251 tells that the decimal address is 8785


Have a nice day :)

Thomas

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,
> 
> 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.
> 
 
The original MBR included in debian-8.7.1-i386-xfce-CD-1.iso was 
delivered with the following values (use a monospace font):

 Boot  System ID   :   First    :    Last    : Relative : Number of:
 Flag              :Cyl Head Sec:Cyl Head Sec:  Sector  :  Sectors :
 80h 00h           :   0   0  1 : 646  63 32 :         0:   1325056:
 00h EFh ??        :1023 254 63 :1023 254 63 :      8524:       608:
 00h 00h           :   0   0  0 :   0   0  0 :         0:         0:
 00h 00h           :   0   0  0 :   0   0  0 :         0:         0:

If a specific BIOS' CHS/LBA translations cannot cope with the above, it 
is no surprise that we get some mess, somewhere.

Regards,
Ady.

Hi,

Ady wrote:
> If a specific BIOS' CHS/LBA translations cannot cope with the above, it
> is no surprise that we get some mess, somewhere.
Currently my suspicion is that the isohdpfx.S code simply mishandles
the two conversion factors which it correctly got from BIOS call
INT 13H AH 8.

>  Boot  System ID   :   First    :    Last    : Relative : Number of:
>  Flag              :Cyl Head Sec:Cyl Head Sec:  Sector  :  Sectors :
>  80h 00h           :   0   0  1 : 646  63 32 :         0:   1325056:
>  00h EFh ??        :1023 254 63 :1023 254 63 :      8524:       608:
The last sector 1325055 and its C/H/S (646, 63, 32) address tell that the
partition table was made under the assumption H/C= 64 and S/H= 32.
That's what hpa prescribed to me for smaller sized isohybrids.

The EFI partition bears the CHS value which says that it is not valid.
See:
  https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries
which says:
  "When a CHS address is too large to fit into these fields, the tuple
   (1023, 254, 63) is typically used today,"

Since the only intended audience of the partition is UEFI firmware,
i'd say it is safe to assume that it can address by LBA.


I will have to examine whether the invalidated CHS value is an old bug in
libisofs-1.3.6 (and maybe fixed meanwhile) or if there is a reason why
the EFI partition got no valid CHS addresses.


Have a nice day :)

Thomas