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

Thomas Schmitt scdbackup at gmx.net
Fri Mar 24 06:12:19 PDT 2017


Hi,

i am looking now at the code which i assume loads the rest of isolinux.bin.

The entry point for program execution from the MBR is obviously at

  http://git.zytor.com/syslinux/syslinux.git/tree/core/isolinux.asm#n186

(Do i get it right that this is the Intel syntax ? (Gronfff))

If POP yields the victim of the most recent not yet popped PUSH, then
this does not look correctly coordinated with the MBR.

isohdpfx.S has:

	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 */

	pushw	%bx		/* -20: EBIOS flag */
	
isolinux.asm has:

		; The following values will have been pushed onto the
		; entry stack:
		;	- partition offset (qword)
		;	- ES
		;	- DI
		;	- DX (including drive number)
		;	- CBIOS Heads
		;	- CBIOS Sectors
		;	- EBIOS flag
		;       (top of stack)

  _start_hybrid:
		pop cx				; EBIOS flag
		pop word [cs:bsSecPerTrack]
		pop word [cs:bsHeads]
		pop dx
		pop di
		pop es

Shouldn't the sequence of
                pop word [cs:bsSecPerTrack]
                pop word [cs:bsHeads]
be the reverse sequence of
        pushw   %cx             /* -16: Save sectors on the stack */
        pushw   %ax             /* -18: Save heads on the stack */
?


Can it be that the two POPW which would need to swap places are the
two byte groups "8f  06  28  30  2e" and "8f  06  2a  30  5a" near
byte position 64 of isolinux.bin :
  
  fb  c0  78  70  59  2e  8f  06  28  30  2e  8f  06  2a  30  5a

given that isohdpfx.S has:

  HYBRID_MAGIC                    = 0x7078c0fb
  isolinux_hybrid_signature       = 0x7c00+64
  isolinux_start_hybrid           = 0x7c00+64+4

(One may guess that i will propose to patch the ISO at byte 8444*512+70,
 if i get a "yes" on this question.)

---------------------------------------------------------------------

If this is indeed the wrong sequence in isolinux.bin then the riddle
arises why the second try of David with isohdpfc.bin succeeded.

And why do our virtual BIOSes work ? Don't they get the fake EBIOS flag ?
Can it be that isolinux.bin unconditionally first tries "getlinsec_ebios"
before it defaults to "getlinsec_cbios" which is a consumer of
"bsSecPerTrack" and "bsHeads" ?


How can so few bytes impose so many riddles ?


Have a nice day :)

Thomas



More information about the Syslinux mailing list