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

Thomas Schmitt wrote:
> I ponder whether it would be possible to create a diagnostic MBR
> which does not necessarily have to boot but rather tells what the
> isohybrid MBR would perceive: Presence of partition table,
> EBIOS or CBIOS, block address used with INT 13, content of the block
> read by the first INT 13, ...
...
> The diagnostic MBR should only use 432 bytes because at byte 432
> to 435 of the isohybrid MBR there is the 512-byte-block address of
> file isolinux.bin, which was patched in by isohybrid or xorriso.
Yes. What exactly should be printed? Perhaps we'd need several
diagnostic ones if the space is too small.
Or possibly in two parts, if there are four bytes that must be
preserved in the middle, but that might be messy.

Like:
P
or
N for partition table or not. How is the presence of partition table
detected?

And
E
or
C
for EBIOS or CBIOS.

Exactly what block address are you talking about? Do you mean the LBA
(/CHS) address?

The content of a block? Like a hex dump of 512 bytes?
Like ABDEFABDEBDA872342ABD2323784...?


-- 
MartinS

Hi,

i wrote:
> > I ponder whether it would be possible to create a diagnostic MBR
> > [for isohybrid]
MartinS wrote:
> Yes. What exactly should be printed?
All the things which lead to decisions in isohdpfx.S.
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.

- I am quite clueless what the code between "1:" in line 130 and
"next:"
  in line 150 does.

- 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.

- Unclear why "/* Get (C)HS geometry */" is performed in both cases.

- 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.
  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.

  It would be interesting to see what bytes it reads by the first
  pass of the loop.
  If the block content of a real ISO is inconclusive, one could combine
  the MBR with a disk image that bears the block number at the start of
  each block. So one could see which block was actually read when e.g.
  block 8222 was desired.

- Next is the failing magic number test:
	cmpl	$HYBRID_MAGIC,(isolinux_hybrid_signature)
	jne	bad_signature

  Any problem of the real isohybrid MBR should have shown up until
  this point.


Have a nice day :)

Thomas