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

[Ady 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
> 
 
@Thomas,

With the variety of potential combinations, is there really one generic 
"receipt" that can be provided so as to help users (other than those 
using the specific Debian ISO image that was tested by David)?

We seem to be suggesting to just dd' the first 432 bytes of their USB 
devices with Martin's isohybrid .bin20170324 (overwriting their first 
432 bytes that were previously written when they used dd with their 
original isohybrid image on the same USB device). Would this be a 
generic receipt, independently of:

_ the original size of the original isohybrid image?

_ whichever CHS geometry that was used for the isohybrid tool (or 
xorriso's equivalent) when the original isohybrid image was created?

_ whichever combination of boot entries in the El Torito boot catalog?

Or, in other words, which would be the step-by-step instructions for 
users of other isohybrid images? Would they differ according to 
some/any parameter?

The reason I am asking is because we should try to avoid going throw 
dozens of emails the next time we have a similar issue (also for the 
sake of common users and their sanity).

Additionally, improving the documentation regarding the existence, 
usage and goals of the "diag/*.img" images should be part of potential 
generic instructions.

TIA,
Ady.

PS:
@Thomas, in "CHS", the "S" is not really "Sectors per head" but rather 
"Sectors per Track". The term "Sector per head" can potentially be 
confused with a different calculation, and we should want to avoid such 
misunderstandings.