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

Thomas Schmitt wrote:
> I have some problems understanding the details of the program's flow.
> 
> - The code inside PARTITION_SUPPORT is supposed to be inactive with
>   MBR isohdpfx.bin. It belongs to isohybrid --partok which is equivalent
>     to MBRs isohdppx*.bin. Debian uses isohdpfx.bin.
Yes. isohdpfx.bin is generated from isohdpfx.S in which
PARTITION_SUPPORT is not defined. isohdppx.bin us generated from
isohdppx.S which #defines PARTITION_SUPPORT to 1 and #includes
isohdpfx.S.
> - I am quite clueless what the code between "1:" in line 130 and
"next:"
>   in line 150 does.
That piece is to move the running code from (0x0000:)0x7x00 to
somewhere else. The comment says 0x600 and "objdump -D -b binary -m
i8086 -M data16,addr16 bios/mbr/isohdpfx.bin" confirms this.

This is done so the next bootloader can be loaded at 0x7x00, which is
a requirement and/or expected by any bootloader. 
> - Then it tries whether INT 13 AH 41H is supported and if so, patches
>   itself to use INT 13 AH 42H for reading rather than AH 6H.
Yes.
> - Unclear why "/* Get (C)HS geometry */" is performed in both
cases.
You're helped by the comment for the same(?) code in gptmbr.S:
 /* here we computer CHS values or just do some dummy computation for EBIOS */

So it's just for simplicity or lazyness. As the code doesn't do any
harm (supposedly) in that case the coder just lets it run.
> 
> - I assume that
>  movw	   $0x7c00, %bx
>  movw	    $4, %cx		/* Sector count */
>  movl		(lba_offset), %eax
>      2:
>  call	read_sector
>         ...
>         loopw	2b
>   shall load the bytes of isolinux.bin to address 0x7c00.
Yes, I think so. It loads the next bootloader (which is four secors
instead of the usual one) to 0x7c00. It's most likely is isolinux as
it has confirmed the signature (the part that fails for David which
started this thread), right?
>   I know the number 0x7c0 (i.e. with one "0" less) as the default
>   "Load Segment" of El Torito.
>     http://wiki.osdev.org/Boot_Sequence#Master_Boot_Record
>   says "0x0000:0x7c00" and "0x7c0:0x0000 " are the
same. Shrug.
Welcome to more gifts from Intel. Read
<https://en.wikipedia.org/wiki/Real_mode>. In short every address has
sixteen diffent aliases: 0x7c0:0x0000, 0x7bf:0x0010, 0x7be:0x0020,
0x7bd:0x0030, etc is the same memory location!


-- 
MartinS

Hi,

MartinS wrote:
> It's most likely is isolinux as
> it has confirmed the signature (the part that fails for David which
> started this thread), right?
Yep. Firstly because the magic number is compared with the bytes at
  isolinux_hybrid_signature	= 0x7c00+64
which matches the signature's byte position 64 in isolinux.bin.

Secondly because "lba_offset" in
  	movl	(lba_offset), %eax
  2:
  	call	read_sector
is mentioned at the end of the code as
  /* Address of pointer to isolinux.bin */
  lba_offset = _start+432
432 is indeed the byte address where isohybrid or xorriso put the block
address of isolinux.bin.


We seem to roughly understand everything except the reason why there
is no correct signature in the first of the alleged isolinux.bin blocks.

I tested meanwhile:
A xz compressed image of 647 MiB with blocks of recognizable content
has 741720 bytes. (The generating C code is much smaller. It produces
blocks of 128 big endian 32 bit numbers telling the block number.)
So if we had a MBR which prints the content of the first 512 read bytes
we could tell whether they are block aligned and from which block they
come.
(Of course the MBR should not do
  	ljmpw	$0, $isolinux_start_hybrid
then.)


Have a nice day :)

Thomas