Syslinux - Nov 2014 - Boot fails in a VMware player VM - syslinux 6.03

Hi there,

I failed to boot an installer in a VMware player (Version6.0.3 
build-1895310)
using syslinux 6.03, be it off an hybrid ISO image and an USB stick.

Booting succeeds if the VM is set to use a BIOS firmware with both media,
but fails using an efi firmware.

Trying to boot off the ISO image I get an error message "The firmware
    encountered an unexpected exception"

Trying to boot off the USB stick I get a black screen.

In both cases I see in vmplayer*.log:
    VMHSGetDataFileKey: Could not get the dataFileKey from VMDB

I have no idea what that means.

Alas I don't have a real machine with an UEFI firmware to try and see
if the problem occurs only in a VM (and would be very grateful if
a kind soul could do that for me).

I used only official binaries taken directly from the source tarball, as
shown in attached file. This file and the ISO image are also available
in http://slint.fr/misc/testing

In that file you can see:
. the end of the script used to make the ISO image,
. the tree of the ISO file,
. the beginning of /EFI/BOOT/syslinux.cfg,
. the output of "dumpet -h -i <filename>.iso"

As you can see, I've put all needed file in /EFI/BOOT, also copied in the
Fat 12 partition included in /isolinux/efiboot.img

I can add entries in the boot menu as the boot manager finds the
file \EFI\BOOT\bootx64.efi, but get the same behavior using these menu
entries.

I've seen the same error message in the ML but in a different context.

I'm a complete newbie and never used syslinux 6.03 before, so I assume
that's PEBCAK case, any clue appreciated anyway.

Thanks in advance and best regards,
Didier
-------------- next part --------------
#!/bin/bash
# This is the end of a script that creates a polyglot installer for
# Slackware64-14.1
# $SLINT is a directory that hosts the tree to put in the ISO file
# $SLINT/isolinux is already populated with what's needed for BIOS booting
#
# Fifth step: provide stuff needed for UEFI booting
# ================================================#
mkdir -p $SLINT/EFI/BOOT
cp -a $SLINT/isolinux/{f2.txt,initrd.img,isolinux.cfg,message.txt,ter-i16v.psf}
$SLINT/EFI/BOOT
SYSLINUX_SRC="/32-14.1/home/didier/logiciels/syslinux-6.03"
( cd $SLINT/EFI/BOOT
  cp $SYSLINUX_SRC/efi64/efi/syslinux.efi bootx64.efi
  cp $SYSLINUX_SRC/efi64/com32/elflink/ldlinux/ldlinux.e64 .
  cp $SLINT/kernels/huge.s/bzImage .
  mv isolinux.cfg syslinux.cfg
  sed -i 's:/kernels/huge.s/::g' syslinux.cfg
)
# Compute the needed size of our FAT partition
Size=`du -sk $SLINT/EFI | awk '{print $1}'`
Size=$(($Size + ($Size / 10)))
# Make the image, put a filsystem in it
dd if=/dev/zero of=$SLINT/isolinux/efiboot.img bs=1K count=$Size
mkfs.fat -s 2 -S 512 -v $SLINT/isolinux/efiboot.img
# Create a temporary mount point:
MOUNTPOINT=$(mktemp -d)
# Mount the image there
mount $SLINT/isolinux/efiboot.img $MOUNTPOINT
# Put in the image what's needed
mkdir -p $MOUNTPOINT/EFI/BOOT
cp -a $SLINT/EFI/BOOT/* $MOUNTPOINT/EFI/BOOT
umount $MOUNTPOINT
rmdir $MOUNTPOINT
# Sixth step: build the ISO file
# =============================#
Version=14.1
SFX=64
Suffix="_syslinux.6.03"
( cd $SLINT
mkisofs -o /tmp/slint${SFX}-${VERSION}${Suffix}.iso \
-rational-rock -J -A 'Slint hybrid installer ISO' \
-hide-rr-moved \
-v -d -N \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-b isolinux/isolinux.bin \
-c isolinux/isolinux.boot \
-eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF \
-eltorito-boot isolinux/efiboot.img \
-V 'Slint installer' . \
  2>>$TMP/log.txt )
( cd /tmp
  md5sum slint${SFX}-${VERSION}${Suffix}.iso >
slint${SFX}-${VERSION}${Suffix}.iso.md5
)
chown `stat -c %U:%G ${ROOT}` /tmp/slint${SFX}-${VERSION}${Suffix}.iso{,.md5}
echo "/tmp/slint${SFX}-${VERSION}${Suffix}.iso is ready"
# The ISO image is then post-processed with "isohybrid -u
filename.iso"

# The tree of the generated ISO follows

/mnt
|-- EFI
|   `-- BOOT
|       |-- bootx64.efi
|       |-- bzImage
|       |-- f2.txt
|       |-- initrd.img
|       |-- ldlinux.e64
|       |-- message.txt
|       |-- syslinux.cfg
|       `-- ter-i16v.psf
|-- README_SLINT.TXT
|-- SLINT_DATE
|-- isolinux
|   |-- efiboot.img
|   |-- f2.txt
|   |-- initrd.img
|   |-- isolinux.bin
|   |-- isolinux.boot
|   |-- isolinux.cfg
|   |-- ldlinux.c32
|   |-- message.txt
|   |-- setpkg
|   `-- ter-i16v.psf
`-- kernels
    |-- VERSIONS.TXT
    |-- huge.s
    |   |-- System.map.gz
    |   |-- bzImage
    |   `-- config
    |-- memtest
    |   |-- README
    |   `-- memtest
    `-- speakup.s
        `-- README.TXT

7 directories, 27 files

Here is the beginning of /EFI/BOOT/syslinux.cfg:
-------------------------
default 05
prompt 1
timeout 1200
display message.txt
FONT ter_i16v.psf 
F1 message.txt
F2 f2.txt
F3 f3.txt
label speakup.s
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
nomodeset SLACK_KERNEL=huge.s LANG=en_US.utf8
label memtest
  kernel /kernels/memtest/memtest
label 04
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s LANG=nl_NL.utf8
label 04n
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s nomodeset LANG=nl_NL.utf8
label 05
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s LANG=en_US.utf8
label 05n
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s nomodeset LANG=en_US.utf8
label 06
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s LANG=fr_FR.utf8
label 06n
  kernel bzImage
  append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
SLACK_KERNEL=huge.s nomodeset LANG=fr_FR.utf8
------------------

Here is the output of "dumpet -h -i <filename>.iso":

------------------
Validation Entry:
00000000  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 aa 55 55 aa  |.............UU.|
	Header Indicator: 0x01 (Validation Entry)
	PlatformId: 0x00 (80x86)
	ID: ""
	Checksum: 0x55aa
	Key bytes: 0x55aa
Boot Catalog Default Entry:
00000000  88 00 00 00 00 00 04 00 75 58 00 00 00 00 00 00  |........uX......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
	Entry is bootable
	Boot Media emulation type: no emulation
	Media load segment: 0x0 (0000:7c00)
	System type: 0 (0x00)
	Load Sectors: 4 (0x0004)
	Load LBA: 22645 (0x00005875)
Section Header Entry:
00000000  91 ef 01 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
	Header Indicator: 0x91 (Final Section Header Entry)
	PlatformId: 0xef (EFI)
	Section Entries: 1
	ID: ""
Boot Catalog Section Entry:
00000000  88 00 00 00 00 00 18 61 2f 00 00 00 00 00 00 00  |.......a........|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
	Entry is bootable
	Boot Media emulation type: no emulation
	Media load address: 0 (0x0000)
	System type: 0 (0x00)
	Load Sectors: 24856 (0x6118)
	Load LBA: 47 (0x0000002f)
-----------------

> Hi there,
> 
> I failed to boot an installer in a VMware player (Version6.0.3 
> build-1895310)
> using syslinux 6.03, be it off an hybrid ISO image and an USB stick.
> 
> Booting succeeds if the VM is set to use a BIOS firmware with both media,
> but fails using an efi firmware.
> 
> Trying to boot off the ISO image I get an error message "The firmware
>     encountered an unexpected exception"
> 
> Trying to boot off the USB stick I get a black screen.
> 
> In both cases I see in vmplayer*.log:
>     VMHSGetDataFileKey: Could not get the dataFileKey from VMDB
> 
> I have no idea what that means.
> 
> Alas I don't have a real machine with an UEFI firmware to try and see
> if the problem occurs only in a VM (and would be very grateful if
> a kind soul could do that for me).
> 
> I used only official binaries taken directly from the source tarball, as
> shown in attached file. This file and the ISO image are also available
> in http://slint.fr/misc/testing
> 
> In that file you can see:
> . the end of the script used to make the ISO image,
> . the tree of the ISO file,
> . the beginning of /EFI/BOOT/syslinux.cfg,
> . the output of "dumpet -h -i <filename>.iso"
> 
> As you can see, I've put all needed file in /EFI/BOOT, also copied in
the
> Fat 12 partition included in /isolinux/efiboot.img
> 
> I can add entries in the boot menu as the boot manager finds the
> file \EFI\BOOT\bootx64.efi, but get the same behavior using these menu
> entries.
> 
> I've seen the same error message in the ML but in a different context.
> 
> I'm a complete newbie and never used syslinux 6.03 before, so I assume
> that's PEBCAK case, any clue appreciated anyway.
> 
> Thanks in advance and best regards,
> Didier
> 
You are probably imitating / following some procedure used by 
Slackware to create EFI-compatible ISO images. The problem, as 
mentioned in a recent email this last week, is the particularities of 
the documents regarding, in this case, grub2 as EFI bootloader (as 
oppose to documents covering EFI bootloaders in general and clearly 
indicating the specifics about one particular bootloader).

Currently, Syslinux is not capable of booting optical media in EFI 
mode. So your VM, when being set to use EFI and this ISO image as 
virtual boot media, will fail.

I don't know how exactly you are building your virtual HDD to boot in 
EFI mode. In /EFI/BOOT/syslinux.cfg, you could:
_ comment out the FONT directive;
_ comment out the DISPLAY directive;
_ comment out the TIMEOUT directive;
_ keep using "PROMPT 1" and _no_ UI directive (as it is already).

If your HDD image and the VM are built adequately for booting in EFI 
mode, then commenting out these directives should at least give you a 
Syslinux "boot:" prompt when booting to the virtual HDD image (in EFI 
mode). If such initial test is successful, then you could move on to 
additional testing steps. If it fails too (i.e. you don"t get to the 
boot prompt), then some additional info would be needed.

If you are really trying to boot your EFI VM with a (either real or 
virtual) USB drive (instead of using a virtual fixed HDD), then some 
additional considerations might be necessary.

Regards,
Ady.

Hi,

i downloaded
  http://slint.fr/misc/testing/slint64-14.1_syslinux.6.03.iso

Inspection by xorriso-1.3.8:

  xorriso -indev slint64-14.1_syslinux.6.03.iso \
          -report_el_torito plain \
          -report_system_area plain

yields

  El Torito catalog  : 46  1
  El Torito cat path : /isolinux/isolinux.boot
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4       22645
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00  24856          47
  El Torito img path :   1  /isolinux/isolinux.bin
  El Torito img opts :   1  boot-info-table isohybrid-suitable
  El Torito img path :   2  /isolinux/efiboot.img
  xorriso : NOTE : No System Area was loaded

There is neither MBR nor GPT. So booting from USB-stick or other
hard-disk-like device would demand that the UEFI implementation
understands ISO 9660 and knows where to look for efiboot.img.

If presented as (pseudo-)CD-ROM, /isolinux/efiboot.img should
be found and interpreted by UEFI.
Here it probably fails with the known inability of ISOLINUX to
boot via UEFI.

All UEFI capable ISOs known to me use a GRUB2 produced FAT image
file as UEFI boot image. E.g. debian-7.5.0-amd64-netinst.iso :

  El Torito catalog  : 847  1
  El Torito cat path : /isolinux/boot.cat
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        1072
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00    896         848
  El Torito img path :   1  /isolinux/isolinux.bin
  El Torito img opts :   1  boot-info-table isohybrid-suitable
  El Torito img path :   2  /boot/grub/efi.img
  System area options: 0x00000102
  System area summary: MBR isohybrid cyl-align-on GPT APM
  ISO image size/512 : 454656
  Partition offset   : 0
  MBR heads per cyl  : 64
  MBR secs per head  : 32
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0x00            0       454656
  MBR partition      :   2   0x00  0xef         3392          896
  MBR partition path :   2  /boot/grub/efi.img
  GPT                :   N  Info
  GPT disk GUID      :      b3aadf1d79f37941a9e16e9d465702f1
  GPT entry array    :      12  208  overlapping
  GPT lba range      :      64  454602  454655
  GPT partition name :   1  490053004f00480079006200720069006400
  GPT partname local :   1  ISOHybrid
  GPT partition GUID :   1  b3aadf1d79f37941a9e36e9d465702f1
  GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1000000000000001
  GPT start and size :   1  0  454600
  GPT partition name :   2  490053004f004800790062007200690064003100
  GPT partname local :   2  ISOHybrid1
  GPT partition GUID :   2  b3aadf1d79f37941a9e26e9d465702f1
  GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   2  0x1000000000000001
  GPT start and size :   2  3392  896
  GPT partition path :   2  /boot/grub/efi.img
  APM                :   N  Info
  APM block size     :      2048
  APM gap fillers    :      0
  APM partition name :   1  EFI
  APM partition type :   1  Apple_HFS
  APM start and size :   1  848  224
  APM partition path :   1  /boot/grub/efi.img

The UEFI boot image /boot/grub/efi.img is advertised by
El Torito for CD, by MBR, GPT, and APM for USB-stick.
So the firmware has a lot of entry points to pick from.
(I believe that the APM equipment is put here in vain.
 It does not harm, nevertheless.)

I cannot tell how the GRUB2 image file was created.
It is done by the ISO production scripts of the distros.
At least with Debian, Ubuntu, Archlinux, and Fedora.


Have a nice day :)

Thomas

On 10/11/2014 04:02, Ady wrote:
 >
 >> Hi there,
 >>
 >> I failed to boot an installer in a VMware player (Version6.0.3
 >> build-1895310)
 >> using syslinux 6.03, be it off an hybrid ISO image and an USB stick.
 >>
 >> Booting succeeds if the VM is set to use a BIOS firmware with both 
media,
 >> but fails using an efi firmware.
 >>
 >> Trying to boot off the ISO image I get an error message "The
firmware
 >>     encountered an unexpected exception"
 >>
 >> Trying to boot off the USB stick I get a black screen.
 >>
 >> In both cases I see in vmplayer*.log:
 >>     VMHSGetDataFileKey: Could not get the dataFileKey from VMDB
 >>
 >> I have no idea what that means.
 >>
 >> Alas I don't have a real machine with an UEFI firmware to try and
see
 >> if the problem occurs only in a VM (and would be very grateful if
 >> a kind soul could do that for me).
 >>
 >> I used only official binaries taken directly from the source tarball,
as
 >> shown in attached file. This file and the ISO image are also available
 >> in http://slint.fr/misc/testing
 >>
 >> In that file you can see:
 >> . the end of the script used to make the ISO image,
 >> . the tree of the ISO file,
 >> . the beginning of /EFI/BOOT/syslinux.cfg,
 >> . the output of "dumpet -h -i <filename>.iso"
 >>
 >> As you can see, I've put all needed file in /EFI/BOOT, also copied
in the
 >> Fat 12 partition included in /isolinux/efiboot.img
 >>
 >> I can add entries in the boot menu as the boot manager finds the
 >> file \EFI\BOOT\bootx64.efi, but get the same behavior using these menu
 >> entries.
 >>
 >> I've seen the same error message in the ML but in a different
context.
 >>
 >> I'm a complete newbie and never used syslinux 6.03 before, so I
assume
 >> that's PEBCAK case, any clue appreciated anyway.
 >>
 >> Thanks in advance and best regards,
 >> Didier
 >>
 >
 > You are probably imitating / following some procedure used by
 > Slackware to create EFI-compatible ISO images. The problem, as
 > mentioned in a recent email this last week, is the particularities of
 > the documents regarding, in this case, grub2 as EFI bootloader (as
 > oppose to documents covering EFI bootloaders in general and clearly
 > indicating the specifics about one particular bootloader).

That's right, what I did imitates the procedure used by Slackware that
uses grub2 as EFI bootloader.

 > Currently, Syslinux is not capable of booting optical media in EFI
 > mode. So your VM, when being set to use EFI and this ISO image as
 > virtual boot media, will fail.

I assumed that post-precessing the ISO image with "isohybrid -u" (as I
do
when using grub2 as EFI bootloader would work the same when using syslinux
as an EFI bootloder.

So that was a wrong assumption... Maybe a warning about that in this
wiki page:
http://www.syslinux.org/wiki/index.php/Isohybrid
wouldn't be useless, then...

 > I don't know how exactly you are building your virtual HDD to boot in
 > EFI mode. In /EFI/BOOT/syslinux.cfg, you could:
 > _ comment out the FONT directive;
 > _ comment out the DISPLAY directive;
 > _ comment out the TIMEOUT directive;
 > _ keep using "PROMPT 1" and _no_ UI directive (as it is
already).
 >
 > If your HDD image and the VM are built adequately for booting in EFI
 > mode, then commenting out these directives should at least give you a
 > Syslinux "boot:" prompt when booting to the virtual HDD image
(in EFI
 > mode). If such initial test is successful, then you could move on to
 > additional testing steps. If it fails too (i.e. you don"t get to the
 > boot prompt), then some additional info would be needed.

I'm using an hybrid ISO image. I tried to comment out those dierctives
in /EFI/BOOT/syslinux.cfgto no avail: I still get the same error message
at (failed) boot in vmplayer:
        "The firmware encountered an unexpected exception"

 > If you are really trying to boot your EFI VM with a (either real or
 > virtual) USB drive (instead of using a virtual fixed HDD), then some
 > additional considerations might be necessary.

I tried that too with a real USB stick, but still get a black screen
with a message (herd to read as it disappears quicly):
   "Failed to read block: ox2"

I'll give more information in my answer to Thomas.

Thanks and best regards,

Didier

On 10/11/2014 10:46, Thomas Schmitt wrote:
 > Hi,
 >
 > i downloaded
 >   http://slint.fr/misc/testing/slint64-14.1_syslinux.6.03.iso
 >
 > Inspection by xorriso-1.3.8:
 >
 >   xorriso -indev slint64-14.1_syslinux.6.03.iso \
 >           -report_el_torito plain \
 >           -report_system_area plain
 >
 > yields
 >
 >   El Torito catalog  : 46  1
 >   El Torito cat path : /isolinux/isolinux.boot
 >   El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt 
Ldsiz         LBA
 >   El Torito boot img :   1  BIOS  y   none  0x0000  0x00 4       22645
 >   El Torito boot img :   2  UEFI  y   none  0x0000  0x00 
24856          47
 >   El Torito img path :   1  /isolinux/isolinux.bin
 >   El Torito img opts :   1  boot-info-table isohybrid-suitable
 >   El Torito img path :   2  /isolinux/efiboot.img
 >   xorriso : NOTE : No System Area was loaded
 >
 > There is neither MBR nor GPT. So booting from USB-stick or other
 > hard-disk-like device would demand that the UEFI implementation
 > understands ISO 9660 and knows where to look for efiboot.img.

I feel ashamed. I forgot to post-process the ISO image you downloaded,
sorry.

I've now uploaded a new one, post processed with "isohybrid -u".
Now I get this:

bash-4.2# xorriso -indev  slint64-14.1_syslinux.6.03-1.iso \
 >        -report_el_torito plain  \
 >         -report_system_area plain
xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 34 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is 
set to be discarded
Drive current: -indev 'slint64-14.1_syslinux.6.03-1.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR isohybrid cyl-align-on GPT
Media summary: 1 session, 64279 data blocks,  126m data, 19.3g free
Volume id    : 'Slint installer'
El Torito catalog  : 46  1
El Torito cat path : /isolinux/isolinux.boot
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt Ldsiz         LBA
El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4 22645
El Torito boot img :   2  UEFI  y   none  0x0000  0x00 24856          47
El Torito img path :   1  /isolinux/isolinux.bin
El Torito img opts :   1  boot-info-table isohybrid-suitable
El Torito img path :   2  /isolinux/efiboot.img
System area options: 0x00000102
System area summary: MBR isohybrid cyl-align-on GPT
ISO image size/512 : 257116
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x80  0x00            0       258048
MBR partition      :   2   0x00  0xef          188        24856
MBR partition path :   2  /isolinux/efiboot.img
GPT                :   N  Info
GPT disk GUID      :      19cb47a8df735246a8e1a5c62c8fd21d
GPT entry array    :      2  128  overlapping
GPT lba range      :      34  258014  258047
GPT partition name :   1 
490053004f004800790062007200690064002000490053004f00
GPT partname local :   1  ISOHybrid ISO
GPT partition GUID :   1  4c223dc99370cc4fb287af7563e56c90
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x0000000000000000
GPT start and size :   1  0  257116
GPT partition name :   2  490053004f00480079006200720069006400
GPT partname local :   2  ISOHybrid
GPT partition GUID :   2  3f313f0c55e5934ab38a447275cf45b1
GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   2  0x0000000000000000
GPT start and size :   2  188  24856
GPT partition path :   2  /isolinux/efiboot.img
bash-4.2#

Unfortunately I am unable to decipher that and analyze the differences
with the output of that command applied to debian-7.5.0-amd64-netinst.iso.

But as you are the author of xorriso maybe it shouls be easier for you!

 > If presented as (pseudo-)CD-ROM, /isolinux/efiboot.img should
 > be found and interpreted by UEFI.
 > Here it probably fails with the known inability of ISOLINUX to
 > boot via UEFI.

That's would be my assumption, yes. Unfortunately I was not aware of that
inability before testing.


 > All UEFI capable ISOs known to me use a GRUB2 produced FAT image
 > file as UEFI boot image. E.g. debian-7.5.0-amd64-netinst.iso :
 >   El Torito catalog  : 847  1
 >   El Torito cat path : /isolinux/boot.cat
 >   El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt 
Ldsiz         LBA
 >   El Torito boot img :   1  BIOS  y   none  0x0000  0x00 4        1072
 >   El Torito boot img :   2  UEFI  y   none  0x0000  0x00 896         848
 >   El Torito img path :   1  /isolinux/isolinux.bin
 >   El Torito img opts :   1  boot-info-table isohybrid-suitable
 >   El Torito img path :   2  /boot/grub/efi.img
 >   System area options: 0x00000102
 >   System area summary: MBR isohybrid cyl-align-on GPT APM
 >   ISO image size/512 : 454656
 >   Partition offset   : 0
 >   MBR heads per cyl  : 64
 >   MBR secs per head  : 32
 >   MBR partition table:   N Status  Type        Start Blocks
 >   MBR partition      :   1   0x80  0x00            0 454656
 >   MBR partition      :   2   0x00  0xef         3392 896
 >   MBR partition path :   2  /boot/grub/efi.img
 >   GPT                :   N  Info
 >   GPT disk GUID      :      b3aadf1d79f37941a9e16e9d465702f1
 >   GPT entry array    :      12  208  overlapping
 >   GPT lba range      :      64  454602  454655
 >   GPT partition name :   1 490053004f00480079006200720069006400
 >   GPT partname local :   1  ISOHybrid
 >   GPT partition GUID :   1  b3aadf1d79f37941a9e36e9d465702f1
 >   GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
 >   GPT partition flags:   1  0x1000000000000001
 >   GPT start and size :   1  0  454600
 >   GPT partition name :   2 490053004f004800790062007200690064003100
 >   GPT partname local :   2  ISOHybrid1
 >   GPT partition GUID :   2  b3aadf1d79f37941a9e26e9d465702f1
 >   GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
 >   GPT partition flags:   2  0x1000000000000001
 >   GPT start and size :   2  3392  896
 >   GPT partition path :   2  /boot/grub/efi.img
 >   APM                :   N  Info
 >   APM block size     :      2048
 >   APM gap fillers    :      0
 >   APM partition name :   1  EFI
 >   APM partition type :   1  Apple_HFS
 >   APM start and size :   1  848  224
 >   APM partition path :   1  /boot/grub/efi.img
 >
 > The UEFI boot image /boot/grub/efi.img is advertised by
 > El Torito for CD, by MBR, GPT, and APM for USB-stick.
 > So the firmware has a lot of entry points to pick from.
 > (I believe that the APM equipment is put here in vain.
 >  It does not harm, nevertheless.)

As you can see above in my case /isolinux/efiboot.img is advertised by
El Torito for MBR and GPT
 >
 > I cannot tell how the GRUB2 image file was created.
 > It is done by the ISO production scripts of the distros.
 > At least with Debian, Ubuntu, Archlinux, and Fedora.

At least I can give you that information for Slackware ;)
http://mirrors.slackware.com/slackware/slackware64-14.1/EFI/BOOT/make-grub.sh

I have uploaded in http://slint.fr/misc/testing following files:
  # post-processed, otherwise identical
   to slint64-14.1_syslinux.6.03.iso
slint64-14.1_syslinux.6.03-1.iso.md5
slint64-14.1.iso # that's not a genuine Slackware installer, but the EFI
   bootloader comes from Slackware (in this case syslinux 4.06 is used
   for the BIOS bootloader)
slint64-14.1.iso.md5
syslinux-6.03.txt # gathers commands applied to
   slint64-14.1_syslinux.6.03-1: worriso => dd => gdisk on the USB stick
grub.txt # same commands applied to slint64-14.1.iso

I saw this message output of gdisk:
   "Warning! Main partition table overlaps the first partition by 34 
blocks!"
But as it is present in both cases, that can hardly explain the difference
in behavior when trying to boot off the USB sticks in a VM:
slint64-14.1.iso => shows te GRUB menu as expected
slint64-14.1_syslinux.6.03-1.iso => black screen, blinking error message:
   "Failed to read block: ox2"

 > Have a nice day :)
 >
 > Thomas

Thanks and best regards,

Didier