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

Thomas Schmitt wrote:
> David Christensen wrote:
> > # fdisk -l /dev/sdc
> > WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'!
The util
> > fdisk doesn't support GPT.
> 
> That's actually a bug in fdisk. The GPT is invalid because it is not
> announced by a "Protective MBR".
> 
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/sdc1   *           0     1325055      662528    0  Empty
> 
> "Empty" is not a realistic statement but just a human readable
representation
> of partition tye 0x0. It is unusual but needed to avoid that UEFI sees
> partition 2 as nested partition inside partition 1.
> 
> > # parted /dev/sdc u s p
> > Warning: /dev/sdc contains GPT signatures, indicating that it has a
GPT
> > table.  However, it does not have a valid fake msdos partition table,
as
> > it should.
> 
> Smarter than fdisk.
> 
> > Is this a GPT partition table?
> > Yes/No? yes
> > Error: Both the primary and backup GPT tables are corrupt.
> 
> That's because of the nested GPT partitions, i assume.
Well, I consider warning and giving output of the existing MBR that it
does understands better than just bailing out like parted does.

I have been having successful outputs from gdisk in cases like
this, IIRC. Try that.
> > I need a debugging version of whatever program is generating the error
> > message "isolinux.bin missing or corrupt".
> 
> That would be the MBR code at bytes 0 to 432 of the ISO.
> Source code (assembler) is at
>   http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S
> 
> It's a very narrow piece of space for a program. One may re-use the
> "nop" bytes at label "_start:". They serve as fake
Apple Partition Map
> header block.
> If the first ".byte 0x33, 0xed" before the "nop"s gets
removed then the
> second one after the "nop"s needs to be removed, too.
Why? There's no reason from coding perpesctive. That's an xor bp, bp.


-- 
MartinS

Hi,

MartinS wrote:
> > > Then you'd want the x86 manuals from amd or intel for the
instructions
> > > themselves but they are documented backwards.
i wrote:
> > What do you mean by this statement ?
> Haven't you read the manual yet?...
> "info gas machine i386 i386-syn i386-var".
I still don't get the "backwards" aspect. (Probably not enough
background
knowledge.)

> > If the first ".byte 0x33, 0xed" before the "nop"s
gets removed then the
> > second one after the "nop"s needs to be removed, too.
> Why? There's no reason from coding perpesctive. That's an xor bp,
bp.
You are right. My own program lets the second instance survive and
only overwrites the first one.
I thought it would have side effects which would be reverted by the
second command.

These bytes shall do nothing in case that no Apple Partition Map gets
announced. With isohybrid option --mac or xorrisofs -isohybrid-apm-hfsplus,
the first 32 bytes get replaced by a pseudo APM header:

  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

which interpreted as x86 code shall still do nothing.


Have a nice day :)

Thomas