[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

[Martin Str|mberg]

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