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

Hi,

Gene Cumm wrote:
> it seems the stack format got
> set, changed, then mostly reverted back, with this code being the last
> piece missing from 2009.
The commit to isohdpfx.S of 2009-05-31 looks incomplete.
The sequence of the stack pointers was swapped, but the sequence of
stack pushes was not.
 
https://git.kernel.org/pub/scm/boot/syslinux/syslinux.git/commit/mbr/isohdpfx.S?id=2f92affcce5ffef4da90fe44bcac5a4db45df25f

> Finding a system that
> doesn't seem to properly support LBA/EBIOS reads is increasingly
> difficult due to age.
It is now easier to force C/H/S for both MBR and isolinux.bin because
of the "Clear EBIOS flag" code piece.
A isohdpfc with "jmp" instead of "jc" after INT 13 AH 41,
derived from
the new code would instruct isolinux.bin to use C/H/S addressing, too.


I just tested this replacement by locating the "jc" instruction by its
neighbor "cmpw $0xaa55, %bx" at byte 88 and changing it to
"jmp":

  echo -n $'\xeb' | dd conv=notrunc bs=1 seek=88 count=1
of="$iso"

It still boots in qemu to the first graphical Debian menu.
The "ISOLINUX 6.03 ..." messages vanishes too fast for my eyes.

So i damage the ISO to prevent booting the Debian payload.
For that purpose i obtain the 2048-block address of isolinux.cfg 

  xorriso -indev "$iso" -find /isolinux/isolinux.cfg -exec report_lba
--

This reports:

  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,   303939 ,        1 ,      157 ,
'/isolinux/isolinux.cfg'

I flatten its content block to zero:

  dd if=/dev/zero conv=notrunc bs=2048 count=1 seek=303939 of="$iso"

Now booting by qemu says

  ISOLINUX 6.03 20150819 CHDD Copyright ...and.so.on...
  No DEFAULT or UI configuration directive found!
  boot:

"CHDD" confirms that the slightly modified MBR really told
isolinux.bin
to use C/H/S addressing although SeaBIOS advertises LBA.

Our previous qemu experiments with the old MBR code did not bring 
isolinux.bin to C/H/S so that Martin and i did not see the stack
interface problem on the first hand.


Have a nice day :)

Thomas

>From Martin's isolinux.bin.20170324, I (kind of) understand the first 3 
bytes:
33 ED 90 

Then, the next "90"s are probably originiated from the
"nop"s in:
 
http://repo.or.cz/syslinux.git/blobdiff/c210e571f61eeb898fadbb6f47d4a2c8
2e5bfbfd..2c3a24e5f4b807ec31595227afa59a818c060ca9:/mbr/isohdpfx.S 

So, why the original isohybrid image from Debian and many other 
isohybrid images have mostly (but not all) "00s" in place of the
"90s"?
(Considering that these images are generated mostly by xorriso, perhaps 
Thomas might be able to answer?)

To ilustrate what I mean (and what I'm trying to understand), I am 
presenting here the first part of Martin's isolinux.bin20170324 and the 
respective part from the original isohyrbid image from Debian (note: 
the strange format I am presenting them is intentional):

Martin's:

33 ED 90 
90 90 90 
90 90 
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 

Original Debian's bin:
45 52 08 
00 00 00 
90 90 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

TIA,
Ady.

Hi,

Ady wrote:
> so, why the original isohybrid image from Debian and many other 
> isohybrid images have mostly (but not all) "00s" in place of the
"90s"?
That's a fake Block0 of an Apple Partition Map. Part of mjg's layout.
Caused by isohybrid option --mac or xorrisofs option -isohybrid-apm-hfsplus.

* Fedora has it with EFI FAT filesystem in one partition and a HFS filesystem
  in another partition.
* Debian and Ubuntu have it only for the EFI FAT partition.
* ArchLinux 2016 has no APM.
* Gentoo 2016 varies from BIOS-only to full Fedora BIOS+EFI+HFS equipment.
* OpenSuSE last time i looked had no APM and no GPT, but self made EFI
  partition entry in MBR partition table. isohybrid without --uefi and
  then custom post processing.

debian-8.7.1-i386-xfce-CD-1.iso has:

00000000 :    45  52  08  00  00  00  90  90  00  00  00  00  00  00  00  00
               E   R                                                        
       0 :    69  82   8   0   0   0 144 144   0   0   0   0   0   0   0   0

00000010 :    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
                                                                            
      16 :     0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

My own cheat sheet:

  https://dev.lovelyhq.com/libburnia/libisofs/blob/master/doc/boot_sectors.txt

says:
---------------------------------------------------------------------
...
                           Apple Partition Map (APM)
...
Sources:
    http://mjg59.dreamwidth.org/11285.html
   
http://opensource.apple.com/source/IOStorageFamily/IOStorageFamily-116/IOApplePartitionScheme.h
(typedef struct Block0)
    http://www.informit.com/articles/article.aspx?p=376123&seqNum=3
    syslinux-4.05/utils/isohybrid.c
...
The layout of a Block0 of an APM is:

Byte Range | Value      | Meaning (all numbers are stored big endian)
---------- | ---------- | ----------------------------------------------------
   0 -   1 | sig        | Signature 0x45 = 'E' , 0x52 = 'R'
   2 -   3 | block_size | 0x0800 = 2048
   4 -   7 | block_count| Number of blocks covered by APM
           |            | Often some x86-harmless dummy. E.g. 0x9090 = 37008
           |            | or 0xeb02ffff = 3,942,842,367
   8 -   9 | dev_type   | obscure: "device type"
  10 -  11 | dev_id     | obscure: "device id"
  12 -  15 | drv_data   | obscure: "driver data"
  16 -  17 | drv_count  | obscure: "driver descriptor count"
  18 -  81 | drv_map    | obscure: "driver descriptor table"
           |            |          with 8 entries of 16 bytes each
  82 - 511 | reserved   |
---------- | ---------- | ----------------------------------------------------

The SYSLINUX program isohybrid.c overwrites the first 32 bytes of this
layout by its dummy values. It uses the small block_count 0x00009090 and
sets all bytes up to 31 to 0.
...
---------------------------------------------------------------------

It is a lucky incident that the signature "ER" of an APM is x86
program
code with no undesirable effects. Else one could not combine APM and MBR.

A decisive trick is to set APM block size to 2048.
Thus the first 2048 bytes are considered to be part of Block0.
We need the bytes from 32 to 512 as MBR program code and partition table.
At 512 to 1023 is the GPT header block which points to the GPT entries
array located after the end of the APM entries array.


Have a nice day :)

Thomas