[Testers Wanted] Installer using goofiboot for UEFI booting

Didier Spaier · 01-16-2016, 10:00 AM

I just uploaded a new ISO in http://slint.fr/testing/slint64-current_goofiboot/

Changes:

A kernel 4.4.0 is used
xorriso is used instead of mkiosfs to build the ISO
the file is smaller, as the EFI boot image's size has decreased from 400M to 64M[1]

Booting under UEFI works with VirtualBox and VMware player, so please test priority on bare metal.

If you want to know how that's done, see http://slint.fr/testing/slint-curren...t-goofiboot.sh

Incidentally compiling on Slackware64 current libburn, libisofs and libiosburn using the SlackBuilds provided @ http://slackbuilds.org succeeded.

[1]Using mkisofs I couldn't boot with a smaller size set in the dd command although the content weighs less than 62M. I will probably never know why.

scdbackup · 01-16-2016, 12:38 PM

Hi,

thank you for flying xorriso.

It seems that you ran SYSLINUX program isohybrid with option --uefi.
Actually an old version which has several recognizable small flaws.
(E.g. pseudo chinese partition names.)

You may get the effect of the isohybrid run by xorriso -as mkisofs
options

Code:

-isohybrid-mbr ...path/to/syslinux/file/isohdpfx.bin

and after the option which sets file /efi.img as boot image

Code:

-isohybrid-gpt-basdat

> Using mkisofs I couldn't boot with a smaller size set in the dd
> command although the content weighs less than 62M. I will probablyi
> never know why.

If it is about the size of /efi.img, then 64 MB possibly was
represented in The El Torito boot catalog by size value 0.
That's because the field is 16 bit unsigned and counts blocks of
512 bytes. Maximum representable size is 32 MB - 512.

It would be ok for an EFI El Torito boot image to have size 0,
because UEFI 2.4 12.3.2.1 prescribes:
"If the value of Sector Count is set to 0 or 1, EFI will
assume the system partition consumes the space from the beginning
of the “no emulation” image to the end of the CD-ROM."

But the isohybrid program uses this information to produce
MBR and GPT partition table entries. There you need the real
size ... or at least a more realistic one.

xorriso up to recently curbed the Load Size of all El Torito
boot images to 65535.
But be warned that the next version of xorriso will put 0 into
the size field of the El Torito catalog entry of an oversized
EFI boot image / partition.

So program isohybrid will probably produce similar problems as
with mkisofs and image size 64 MiB. (Consider to use above
options which make the run of program isohybrid obsolete.)

Have a nice day

Thomas

Didier Spaier · 01-16-2016, 05:52 PM

Hi,

Quote:

Originally Posted by scdbackup

thank you for flying xorriso.

Thank you Thomas, for xorriso

Quote:

It seems that you ran SYSLINUX program isohybrid with option --uefi.
Actually an old version which has several recognizable small flaws.
(E.g. pseudo chinese partition names.)

You may get the effect of the isohybrid run by xorriso -as mkisofs options

Code:

-isohybrid-mbr ...path/to/syslinux/file/isohdpfx.bin

and after the option which sets file /efi.img as boot image

Code:

-isohybrid-gpt-basdat

Thanks for the heads-up. I remember that you mentioned that on the syslinux mailing list and will follow this advice.

Quote:

> Using mkisofs I couldn't boot with a smaller size set in the dd
> command although the content weighs less than 62M. I will probably
> never know why.

If it is about the size of /efi.img, then 64 MB possibly was
represented in The El Torito boot catalog by size value 0.
That's because the field is 16 bit unsigned and counts blocks of
512 bytes. Maximum representable size is 32 MB - 512.

It would be ok for an EFI El Torito boot image to have size 0,
because UEFI 2.4 12.3.2.1 prescribes:
"If the value of Sector Count is set to 0 or 1, EFI will
assume the system partition consumes the space from the beginning
of the no emulation image to the end of the CD-ROM."

But the isohybrid program uses this information to produce
MBR and GPT partition table entries. There you need the real
size ... or at least a more realistic one.

Maybe I was not clear about what I tried, so here goes.

First, I used an mkisofs command and set the size of efi.img to 64M. No luck.
Then I increased the size of efi.img progressively. Only with a size of 400M (big waste of space, of course) I could boot the ISO in a VM. I still do not understand why this huge increase was needed by the VM I tried to boot in.
Then I saw that Solus-1.0 was built with a size of efi.img set to 30M, but also that they use this command to build the ISO, in the script https://git.solus-project.com/common...age-creator.py

Code:

        cmd = """xorriso -as mkisofs -U -A "(DESC)s" -V "(DESC)s" \
    -volset "(DESC)s" -J -joliet-long -r -v -T -x ./lost+found \
    -o %(ISOFILE)s \
    -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 \
    -boot-info-table -eltorito-alt-boot -e efi.img -no-emul-boot  .""" % { 'DESC': label, 'ISOFILE': filename }

So I ended up with this dd command (but a further useless renaming that I will get rid of):

Code:

dd if=/dev/zero of=efi.img bs=1 count=0 seek=64M

and this xorriso command:

Code:

xorriso -as mkisofs -U -A "@xorriso@" -V "SLINT_INSTALLER64_CURRENT" \
    -J -joliet-long -r -v \
    -o $PATHTOISO \
    -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot \
    -boot-info-table -eltorito-alt-boot -e efi.img -no-emul-boot .

This works with a size of efi.img's content of 65 259 776 bytes.

FYI the script is http://slint.fr/testing/slint-curren...t-goofiboot.sh

Quote:

xorriso up to recently curbed the Load Size of all El Torito boot images to 65535.
But be warned that the next version of xorriso will put 0 into
the size field of the El Torito catalog entry of an oversized
EFI boot image / partition.

So program isohybrid will probably produce similar problems as
with mkisofs and image size 64 MiB. (Consider to use above
options which make the run of program isohybrid obsolete.)

Here I could have a problem. Currently xorriso just warns (but this doesn't prevent booting), as expected considering what you wrote above:

Code:

xorriso : WARNING : Boot image load size exceeds 65535 blocks. Will record 65535 in El Torito.

Do you mean that in the future I won't be able to boot, even using the advised options?

I have a another request.

Knowing that Ikey Doherty encounter difficulties to provide current ISOs able to boot at the moment, I tried to help. I downloaded an official Solus-1.0.iso and rebuilt it, but didn't succeed either to make a bootable one.

Could you have a look at this (bad) ISO here and tell me what's wrong with it? You will find the script I used to build it in the same directory.

NB the script copies BOOTX64.EFI and goofibootx64.efi (actually the same file under two names) in efi.img because goofiboot now ships a different file and I wanted to produce a clone of the released ISO.

As this is off topic wrt this thread if we need to discuss this further this could be via email ( <my first name> slint <dot> fr ).

Thanks for your time.

Have a good day.

scdbackup · 01-17-2016, 02:16 AM

Hi,

> I increased the size of efi.img progressively.

What step size did you use for increasing ?
The Load Size counter of El Torito would roll over every 32 MiB.

Is there some of your old mkisofs produced ISOs available
for inspection ?

This size is normally only used when booting from CD/DVD/BD.
isohybrid.c is not smart enough to determine data file sizes in
the ISO image. It rather reads the El Torito boot catalog and
takes the size recorded there. Now if this is 0 as prescribed
for oversized images by UEFI 2.4, then the partition entries in
MBR and GPT will look like empty.

> Currently xorriso just warns
> xorriso : WARNING : Boot image load size exceeds 65535 blocks. Will record 65535 in El Torito.
> Do you mean that in the future I won't be able to boot, even using the advised options?

isohybrid postprocessing will probably make the ISO unbootable
via EFI from USB stick or other hard-disk-like devices.

If you use the xorriso options -isohybrid-mbr and -isohybrid-gpt-basdat
instead of postprocessing, then it should be ok. xorriso will put
0 into the El Torito Load Size and the real size into MBR and GPT
partition table entries.

I am a bit puzzled by the content of /efi.img. Normally one can
see the word "GRUB" in such image files. Not in yours.
But "strings" shows menu configuration text of GRUB Legacy.
Am i getting it right that /efi.img contains GRUB and not SYSLINUX
(still waiting for the first one who succeeds booting SYSLINUX via EFI
from CD).

I will now inspect the Solus ISO. Your local xorriso-1.4.0 is also
able to do :

Code:

xorriso -hfsplus on -indev Solus-1.0.iso -report_el_torito plain -report_system_area plain

This lists the recognized boot entry points in El Torito
and partition tables.

E.g. your current slint64-current-goofiboot.iso yields

Code:

El Torito catalog  : 38  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       32807
El Torito boot img :   2  UEFI  y   none  0x0000  0x00  65535          39
El Torito img path :   1  /isolinux/isolinux.bin
El Torito img opts :   1  boot-info-table isohybrid-suitable
El Torito img path :   2  /efi.img
System area options: 0x00000102
System area summary: MBR isohybrid cyl-align-on GPT
ISO image size/512 : 261208
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       262144
MBR partition      :   2   0x00  0xef          156        65535
MBR partition path :   2  /efi.img
GPT                :   N  Info
GPT backup problems:      Implausible header LBA 262142
GPT disk GUID      :      62bd1d6bc3eb81409b9a2d9b238b389a
GPT entry array    :      2  128  overlapping
GPT lba range      :      34  262110  262142
GPT partition name :   1  49534f4879627269642049534f0049534f487962726964004170706c
GPT partname local :   1  卉䡏批楲⁤卉O卉䡏批楲d灁汰
GPT partition GUID :   1  861e8e4a6b1839458691f95b18f39d65
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x0000000000000000
GPT start and size :   1  0  261209
GPT partition name :   2  49534f487962726964004170706c65004170706c
GPT partname local :   2  卉䡏批楲d灁汰e灁汰
GPT partition GUID :   2  ee48b9a9ed09254f80457dcd03e72e98
GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   2  0x0000000000000000
GPT start and size :   2  156  65535
GPT partition path :   2  /efi.img

Have a nice day

Thomas

scdbackup · 01-17-2016, 07:10 AM

Hi,

it turned out that the change of UEFI El Torito Load Size with
oversized boot images is already in released version xorriso-1.4.2.

I repacked the mounted slint64-current-goofiboot.iso by

Code:

# Cut out MBR template file from original ISO
dd if=slint64-current-goofiboot.iso bs=1 count=446 \
   of=slint64-current-goofiboot.mbr

xorriso-1.4.2 -as mkisofs \
  -o slint64-current-goofiboot-ts.iso \
  -V 'SLINT_INSTALLER64_CURRENT' \
  --modification-date='2016011614242700' \
  -isohybrid-mbr slint64-current-goofiboot.mbr \
  -partition_cyl_align on \
  -partition_offset 0 \
  -partition_hd_cyl 64 \
  -partition_sec_hd 32 \
  -c '/isolinux/boot.cat' \
  -b '/isolinux/isolinux.bin' \
     -no-emul-boot -boot-load-size 4 -boot-info-table \
  -eltorito-alt-boot \
  -e '/efi.img' \
     -no-emul-boot -isohybrid-gpt-basdat \
  /mnt/iso

(Options proposed by xorriso command -report_system_area "as_mkisofs".
I show the dd way of obtaining the MBR template, because it works with older
xorriso versions too. xorriso-1.4.2 proposes a lenghty --interval:... text.)

This yields without postprocessing by program "isohybrid"

Code:

El Torito catalog  : 33  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       32802
El Torito boot img :   2  UEFI  y   none  0x0000  0x00      0          34
El Torito img path :   1  /isolinux/isolinux.bin
El Torito img opts :   1  boot-info-table isohybrid-suitable
El Torito img path :   2  /efi.img
System area options: 0x00000102
System area summary: MBR isohybrid cyl-align-on GPT
ISO image size/512 : 262144
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       262144
MBR partition      :   2   0x00  0xef          136       131072
MBR partition path :   2  /efi.img
GPT                :   N  Info
GPT disk GUID      :      6c1df61dbc243a4dbc277e971cb36e20
GPT entry array    :      2  248  overlapping
GPT lba range      :      64  262080  262143
GPT partition name :   1  490053004f00480079006200720069006400
GPT partname local :   1  ISOHybrid
GPT partition GUID :   1  6c1df61dbc243a4dbc257e971cb36e20
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x1000000000000001
GPT start and size :   1  0  262080
GPT partition name :   2  490053004f004800790062007200690064003100
GPT partname local :   2  ISOHybrid1
GPT partition GUID :   2  6c1df61dbc243a4dbc247e971cb36e20
GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   2  0x1000000000000001
GPT start and size :   2  136  131072
GPT partition path :   2  /efi.img

Note the partition sizes of 131072 and the El Torito Ldsiz of 0.
Your original ISO has 65535 at these places.
(Also there is no chinese random text.)

The ISO boots via pseudo EFI from pseudo CDROM

Code:

qemu ... -bios /usr/share/ovmf/OVMF.fd -cdrom slint64-current-goofiboot-ts.iso

I get to a language selection menu and a Linux boots.
(Did not go further than the question about keyboard map.)

It also boots from virtual USB stick

Code:

qemu ... -bios /usr/share/ovmf/OVMF.fd -hda slint64-current-goofiboot-ts.iso

So both changes towards your original ISO seem acceptable to OVMF.

Virtual BIOS boots to a very patient text screen where i shall enter
number codes or else after 2 minutes it promises to boot english.
Tested with both, -cdrom and -hda.

Have a nice day

Thomas

Didier Spaier · 01-17-2016, 07:23 AM

Hi,

thanks for testing, for the feedback and the good news.

I will upgrade xorriso and get rid of isohybrid then.

(OT) I will answer you email about Solus but need some time to investigate further.

Have a nice day.

PS I hope that some day I will have a clear understanding of all these booting-related things and also of all the options listed in your man pages. Maybe in a few years

PPS Maybe you could provide pointers to some _readable_by_newbies_ docs?

scdbackup · 01-17-2016, 08:24 AM

Hi,

> PPS Maybe you could provide pointers to some _readable_by_newbies_ docs?

There is a severe lack of such docs, i fear.

I try to document the essential technical details of the stuff
which i implement. The boot setup could need an own extensible
language.
It would have to cover what is described in
http://bazaar.launchpad.net/~libburn...ot_sectors.txt
by announcing the desired features, by connecting them to data storage
areas in the ISO image, and by equipping them with parameters.

The current option set of the mkisofs emulation is a slowly grown
jungle with surprising interdependencies. Deviating from the
usual paths can become an adventure.

If you want to know how to reproduce a particular ISO boot setup,
let xorriso guess options

Code:

xorriso -hfsplus on -indev image.iso -report_system_area as_mkisofs

If it does not issue WARNING messages then there is a good chance
that the proposed options can produce an equivalent layout.
Some of them might not be needed. Volume Id and modification time
are offered because some boot loader setups need these to find
the ISO among the available devices.

Not all bootable ISOs can be reproduced by xorriso.
E.g. OpenSuSE uses a hatchet and meat glue to produce a mountable
ISO partition after the EFI partition.
Another annoyance are boot image which are hidden from the ISO
directory tree. Easy to produce by xorriso but not easy to
re-produce from a mounted ISO filesystem.

Have a nice day

Thomas

273 · 01-17-2016, 08:29 AM

Quote:

Originally Posted by Didier Spaier

Thanks for the clarification. This (mis?)behavior doesn't bother me much, as the installer is supposed to be run only once. Having to press F2 (of F12, or another key, depending on the computer) to be able to chose this USB key as booting media is acceptable, I think.

But, when you write that after pressing F2 the machine"successfully boots to the menu", did you go one step further and booted one of the language entries proposed? If not, could you please do that?

Sorry I thought I had posted back after you posted the new image. I now see the stick in the menu for boot option in UEFI as well as when I press F2.

Didier Spaier · 01-17-2016, 05:02 PM

So, the xorriso (1.4.2) command is now:

Code:

xorriso -as mkisofs \
    -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin \
    -U \
    -A "@xorriso@" \
    -V "SLINT_INSTALLER64_CURRENT" \
    -J -joliet-long \
    -r \
    -v \
    -o $PATHTOISO \
    -b isolinux/isolinux.bin \
    -c isolinux/boot.cat \
    -no-emul-boot \
    -boot-info-table \
    -eltorito-alt-boot \
    -e efi.img \
    -isohybrid-gpt-basdat \
    -no-emul-boot .

The new ISO is in http://slint.fr/testing/slint64-current_goofiboot/

This works. I can now use 'dd' to write the ISO on an USB stick without post-processing of the ISO by 'isohybrid'.

There is also an unexpected but positive side effect.

Previously booting here was only successful in virtual machines, on bare metal (Lenovo W520) I got error messages:

Code:

Cannot load \kernel: Invalid Parameter

Now I can boot on this physical machine.

There is a small caveat though: I get only a 24x64 terminal after booting. Any clue why?

I attach output of "lsmod|sort".

scdbackup · 01-18-2016, 01:58 AM

Hi,

congrats to your success.

> -A "@xorriso@" \

Is there a special reason why xorriso's default business card in Preparer Id
is not enough ?
Currently the ISO has these settable strings in its PVD:

Code:

$ xorriso -indev slint64-current-goofiboot.iso -pvd_info
...
Volume Id    : SLINT_INSTALLER64_CURRENT
Volume Set Id: 
Publisher Id : 
Preparer Id  : XORRISO-1.4.2 2015.11.28.140001, LIBISOBURN-1.4.2, LIBISOFS-1.4.2, LIBBURN-1.4.2
App Id       : XORRISO-1.4.2 2015.11.28.140001, LIBISOBURN-1.4.2, LIBISOFS-1.4.2, LIBBURN-1.4.2
System Id    : 
CopyrightFile: 
Abstract File: 
Biblio File  : 
Creation Time: 2016011721185200
Modif. Time  : 2016011721185200
Expir. Time  : 0000000000000000
Eff. Time    : 0000000000000000

> Previously [...] on bare metal (Lenovo W520) I got error messages:
> Cannot load \kernel: Invalid Parameter

It might be that the kernel or initrd are located in efi.img in blocks
which have higher numbers than 65535. A picky EFI firmware could take
offense from a filesystem that exceeds its partition.

Did you try both boot media types, CDROM and HDD ?

> I get only a 24x64 terminal after booting. Any clue why?

My knowledge ends when the boot loader successfully has taken over control.

Have a nice day

Thomas

Didier Spaier · 01-18-2016, 07:02 AM

Quote:

Originally Posted by scdbackup

> -A "@xorriso@" \

Is there a special reason why xorriso's default business card in Preparer Id
is not enough ?

This "special reason" is just: not enough attentive reading of your fine manual. I will correct that, thanks.

Quote:

Did you try both boot media types, CDROM and HDD ?

I just did

I can boot the installer from a CDROM in EFI mode on my laptop.

Maybe you had in mind what Ady wrote a while ago http://www.syslinux.org/archives/201...er/022780.html. I am afraid that this remains a good summary of the current situation: no way to boot a .iso including Sylinux 6.03 from an optical media in UEFI mode. That was one of my motivations to try goofiboot associated to a kernel as EFI stub.

Thanks for your help.

Have a nice day

scdbackup · 01-18-2016, 07:48 AM

Hi,

> This "special reason" is just: not enough attentive reading of
> your fine manual. I will correct that, thanks.

It is not wrong. I was just curious.

ECMA-119 is not very clear what "Publisher", "Preparer", and
"Application" shall be.

Publisher:
"the user who specified what shall be recorded"
In my understanding that would be you and those whose work you use.

Preparer:
"the person or other entity which controls the preparation of the data
to be recorded"
That would be xorriso or your production software.
xorriso occupies Preparer Id unless its user gives it a different
value. In this case it offers value "@xorriso@" for Application ID.

Application:
"the specification of how the data are recorded"
That would be the fulfilled expectations of the potential readers.
Something like: "BIOS,EFI,SYSLINUX,GRUB,LINUX"

But one can shift the meaning:
Publisher = you ran the software and also made its upper layers.
Preparer = SYSLINUX, GRUB, Linux prescribe what must be in the ISO.
Application = xorriso made the ISO the way it has to be.

These Ids consume no extra space when being set. They are fixed size
fields in the PVD. Filled with blanks if no other text is set.

> > Did you try both boot media types, CDROM and HDD ?

> I just did

Good to know. The HDD partition size did not change towards xorriso-1.4.0
(if no isohybrid postprocessing is applied). But the CDROM size 0 is
new and only tested roughly with OVMF.

> Maybe you had in mind what Ady wrote a while ago [on SYSLINUX mailing list]

I am aware that nobody yet could make SYSLINUX boot via EFI out
of an ISO filesystem. Regardless of CDROM or HDD.

Everybody uses GRUB.

> That was one of my motivations to try goofiboot associated to a kernel as EFI stub.

So you try to do without any boot loader ?
That's what EFI originally was meant for.

Have a nice day

Thomas

Didier Spaier · 01-18-2016, 04:53 PM

Quote:

Originally Posted by scdbackup

So you try to do without any boot loader ?

I didn't intend to go that far (at least not today) but as you suggested it and just for fun, see here: http://slint.fr/testing/slint64-current_efi-stub/

Procedure to build the ISO

Make an initrd shipping the installer, but don't compress it: it should be just a cpio archive whose name ends in .cpio.
Compile a kernel with this initrd embedded, and also an embedded command line.
We just need bzImage as the modules are already in the initrd.
Rename it BOOTX64.EFI.

Do this:

Code:

#!/bin/sh
# Didier Spaier, Paris, France, 2016
#
# Here the ISO image is written in a VirtualBox shared folder
PATHTOISO=/media/sf_slint-current/slint64-current-efi-stub.iso
TMP=$(mktemp -d)
dd if=/dev/zero of=efi.img bs=1 count=0 seek=62M
mkfs -t vfat efi.img
MOUNTPOINT=$(mktemp -d)
mount -o loop efi.img $MOUNTPOINT
mkdir -p $MOUNTPOINT/EFI/BOOT
cp /tmp/BOOTX64.EFI $MOUNTPOINT/EFI/BOOT
umount $MOUNTPOINT
rmdir $MOUNTPOINT
mv efi.img $TMP
( cd $TMP
xorriso -as mkisofs \
    -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin \
    -U \
    -V "SLINT_INSTALLER64_CURRENT" \
    -J -joliet-long \
    -r \
    -v \
    -o $PATHTOISO \
    -no-emul-boot \
    -eltorito-alt-boot \
    -e efi.img \
    -isohybrid-gpt-basdat \
    -no-emul-boot . \
)
echo "$PATHTOISO is ready"
rm -r $TMP

That's all.

I can boot the ISO in a VM and on bare metal off an USB stick, but I didn't succeed with a CD.

Can someone tell me what's wrong, and possibly give me an advice about the safest command to burn the CD?

slackb0t · 01-18-2016, 09:10 PM

I had some time to kill tonight so I gave it a shot.

-I downloaded the iso and used dd to transfer to a usb stick.
-I booted and hit F12 to get to the 'boot options menu'.
-Then I choose 'boot usb' The menu came up and I was able to scroll up and down.
-I chose 'english' and it started too boot.
-I was then asked to test the keyboard... it worked fine so I chose 1 to more on.
-I was then presented with the login.

All seemed good to me.

Hardware:
Thinkpad X1 Carbon Gen3 (less than a year old)

scdbackup · 01-19-2016, 02:21 AM

Hi,

> Can someone [...] give me an advice about the safest command to burn the CD?

There is not much safety or unsafety with CD burning.
The only constraint to fulfill during burning is that the data blocks
have to be written correctly. All other bootability aspects are in
the data blocks of the ISO. The burn program has no own share in this.

Since you already have xorriso installed, try

Code:

xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed -eject "$PATHTOISO"

The options beginning with -v would also work for cdrecord or wodim.
Normally both do a good job on CD, too. (xorriso gets ahead of them
only with DVD and BD media.)

Well, if it does not boot from virtual CDROM, there is few hope
that it would boot on all firmwares from real CD.

> Can someone tell me what's wrong,

You have no BIOS boot equipment in this ISO. That's unusual.

The option -isohybrid-mbr is obsolete because it has no BIOS
boot image to point the MBR to. It might lead to error messages
when the ISO is booted via BIOS from USB stick.
My qemu default BIOS says "no bootable device", but it could
become more confusing at boot time.

The first option -no-emul-boot and the option -eltorito-alt-boot
are obsolete, because there is no -b or -e preceding them.
They get ignored.

I replayed with mounted goofiboot.iso as file source:

Code:

xorriso -as mkisofs \
  -isohybrid-mbr slint64-current-goofiboot.mbr \
  -U -V "SLINT_INSTALLER64_CURRENT" -J -joliet-long -r -v \
  -o slint64-current-goofiboot-efi-only.iso \
  -e efi.img -isohybrid-gpt-basdat -no-emul-boot \
  /mnt/iso

With

Code:

qemu-system-x86_64 -enable-kvm -m 2048 -bios /usr/share/ovmf/OVMF.fd -cdrom slint64-current-goofiboot-efi-only.iso

it boots to the language menu.
After the due waiting time it boots up an operating system
and asks me for my keyboard layout.

So for me and OVMF of Debian 8 it seems to work nicely as
far as firmware and boot loader are concerned.

Have a nice day

Thomas