Merge lp:~dannf/debian-cd/lp1692876 into lp:~ubuntu-cdimage/debian-cd/ubun3

[dann frazier]

[Adam Conrad (adconrad)]

Seems reasonable. This ends up with -no-emul-boot on the commandline twice, which I assume is harmless, but probably makes sense to clean up in a subsequent commit (including on x86, where this was cargo-culted from).

[Adam Conrad (adconrad)]

Note that '-e' and '--efi-boot' are subtly different (and this revert flips back to the former), quoting the manpage:

 For EFI bootable GRUB boot images use --efi-boot. It performs -boot_image
 grub efi_path= surrounded by two -boot_image "any" "next". Alternative option -e
 from Fedora genisoimage sets bin_path and platform_id for EFI, but performs no
 "next".

I'm not sure which is more "correct" for arm64 here.

[dann frazier (dannf)]

OK - I'll go ahead and merge as-is, and I'll add a card for cleaning up -no-emul-boot and investigating -e vs. --efi-boot on arm64.

[dann frazier (dannf)]

oh, nm - I don't have access to this repo, so up to you to merge I guess :)

[Thomas Schmitt (scdbackup)]

Hi,

i am the author of xorriso.

Looking at your patch and
  http://bazaar.launchpad.net/~dannf/debian-cd/lp1692876/revision/1974/tools/boot/artful/boot-arm64
i must say that the options
  no-emul-boot -boot-load-size 4 -boot-info-table
before -eltorito-alt-boot do not get into effect. They seem to be
remainings of a -b boot image for x86 BIOS.

xorrisofs option
  --efi-boot ...path...
is equivalent to
  -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot -eltorito-alt-boot
(The last -eltorito-alt-boot does not get into effect because no further
El Torito boot image defienition follows.)

But this is not the decisive trick to get the ISO bootable from USB stick.
You need to mark the El Torito EFI boot image as EFI system partition in
either a MBR partition table or in a GPT.

Debian is a bit wasteful by having two copies of the boot image.
Like:

  -nopad \
  -append_partition 2 0xef ...path.on.disk.../efi.img \
  -c /boot.catalog \
  -e /boot/grub/efi.img \
     -no-emul-boot

The disk file ...path.on.disk.../efi.img is also in the input directories
as ./boot/grub/efi.img.

/sbin/fdisk -l then reports

  Device Boot Start End Sectors Size Id Type
  test.iso1 0 329287 329288 160.8M 83 Linux
  test.iso2 329288 331335 2048 1M ef EFI (FAT-12/16/32)

With a sufficiently young xorriso (>= 1.4.4) one can avoid the waste by
pointing the El Torito boot catalog to the appended partition by a
somewhat cryptic string instead of the data file path in the ISO:

  -nopad \
  -append_partition 2 0xef ...path.on.disk.../efi.img \
  -c /boot.catalog \
  -e --interval:appended_partition_2:all:: \

In this case, the file efi.img should not be in the directory trees which
provide the data files for the ISO. One would save a MB:

  Device Boot Start End Sectors Size Id Type
  test.iso1 0 329055 329056 160.7M 83 Linux
  test.iso2 329056 331103 2048 1M ef EFI (FAT-12/16/32)

I would advise to invest the savings into additional xorriso option

  -partition_offset 16 \

which not only will yield a more conventional start of partition 1

  Device Boot Start End Sectors Size Id Type
  test.iso1 64 332111 332648 162.4M cd unknown
  test.iso2 332712 334759 2048 1M ef EFI (FAT-12/16/32)

but also will enable xorriso >= 1.4.8 to let the ISO superblock of
the device claim the range up to the end of partition 2.
So commands like "isosize" will be in sync with the image file size.

  $ expr $(/sbin/isosize test.iso) / 512
  334760

xorriso-1.4.8 will be in Debian "testing" next week. It is already
now available as GNU xorriso
   http://ftpmirror.gnu.org/xorriso/xorriso-1.4.8.tar.gz

The option -partition_offset 16 causes two superblocks. One for the
overall device image (/dev/sdX or /dev/srN) and one for the first
partition (/dev/sdX1). The partition superblock leads to a second
directory tree. Both trees point to the same data file content blocks
by the same paths. So /dev/srN, /dev/sdX, and /dev/sdX1 are mountable.

Have a nice day :)

Thomas

[Thomas Schmitt (scdbackup)]

Hi,

i made a significant typo:
It's
  -no-pad \
not
  -nopad \

Also i showed the wrong fdisk output for
  -e --interval:appended_partition_2:all:: \
without -partition_offset 16. The first partition is actually smaller:

  Device Boot Start End Sectors Size Id Type
  test.iso1 0 328455 328456 160.4M 83 Linux
  test.iso2 328456 330503 2048 1M ef EFI (FAT-12/16/32)

(Base in all tests was debian-8.6.0-arm64-netinst.iso)

Have a nice day :)

Thomas

[Thomas Schmitt (scdbackup)]

Hi,

i also forgot to write option
    -no-emul-boot
after
  -e --interval:appended_partition_2:all:: \

(The default for El Tortio images is floppy emulation. Not good for EFI.)

--------------------------------------------------------------------
Best is i show my tests as complete commands.

The superuser mounts the ISO as substitute for Debian's preparations:

  mount -o loop debian-8.6.0-arm64-netinst.iso /mnt/iso

The normal user fetches the EFI boot image file for use with the tests:

  cp /mnt/iso/boot/grub/efi.img ./efi.img

Debian's way is:

  xorriso -as mkisofs \
     -no-pad -J -o test.iso \
     -append_partition 2 0xef ./efi.img \
     -c /boot.catalog \
     -e /boot/grub/efi.img \
        -no-emul-boot \
     /mnt/iso

Avoiding the duplicate EFI System Partition image:

 xorriso -as mkisofs \
     -no-pad -J -o test.iso \
     -append_partition 2 0xef ./efi.img \
     -c /boot.catalog \
     -e --interval:appended_partition_2:all:: \
        -no-emul-boot \
     /mnt/iso \

To demonstrate that now there is no need for having the image file as data
file in the ISO filesystem, i leave -as mkisofs emulation and perform a
xorriso command to remove efi.img from the ISO before it gets produced:

   -- \
     -rm /boot/grub/efi.img --

My personal favorite is:

 xorriso -as mkisofs \
     -no-pad -J -o test.iso \
     -partition_offset 16 \
     -append_partition 2 0xef ./efi.img \
     -c /boot.catalog \
     -e --interval:appended_partition_2:all:: \
        -no-emul-boot \
     /mnt/iso

I ran the last one also with

  mount -o loop ubuntu-17.04-server-arm64.iso /mnt/iso

Its result inspected with fdisk:

  Device Boot Start End Sectors Size Id Type
  test.iso1 64 1291551 1291488 630.6M cd unknown
  test.iso2 1291552 1292447 896 448K ef EFI (FAT-12/16/32)

(It's useless to test with qemu+OVMF. OVMF boots via El Torito from hard disk
and via partition table from CD-ROM.)

Have a nice day :)

Thomas

[dann frazier (dannf)]

@scdbackup: Thanks for the detailed explanation! I've pushed a new branch here which tries to evolve our code w/ your recommendations, and it seems to work for me:

https://code.launchpad.net/~dannf/debian-cd/lp1692876-2

(I'm not sure if there's a way to force push that over this branch so that the MP comments here remain associated)

It's a series of commits that tries to explain the rationale behind each change - would you mind taking a look to see that I've accurately understood?

Two things I did not (yet) include are the change from -efi-boot to -e and the addition of -no-pad. I'm not sure I understand the difference the former makes in our use case. The latter seems to be for images that are not intended to be burned, while this one certainly could be. Is there a reason that it is no longer relevant?

[Thomas Schmitt (scdbackup)]

Hi,

> https://code.launchpad.net/~dannf/debian-cd/lp1692876-2
> would you mind taking a look to see that I've accurately understood?

1974: Ok.
      It removes the BIOS options which would get wiped away by the
      subsequent -eltorito-alt-boot (and then again by the built-in
      -eltorito-alt-boot of --efi-boot).

1975: Ok.
      The still surplus -eltorito-alt-boot is gone.
      Here you created the capability to boot from USB stick.
      The option -no-emul-boot is still (harmlessly) surplus, because
      of the implicit -eltorito-alt-boot at the end of --efi-boot.
      So -no-emul-boot, which would be necessary with -e, has no no
      boot image to apply to.

1976: Ok.

1977: Ok.
      (Now get xorriso-1.4.8 to get its beneficial ISO size claim which
       protects the EFI partition from mishaps by established procedures
       which rely on /sbin/isosize being equal to image file size.)

> Two things I did not (yet) include are the change from -efi-boot to -e

There is no hard need to do so. If you stay with --efi-boot, then you
should remove the -no-emul-boot option.
If you switch to -e, then the -no-emul-boot will be necessary.

> and the addition of -no-pad.

This will save 300 KiB of image size.

> I'm not sure I understand the difference the former makes in our use case.

Effectively there is no difference.
The surrounding implicit -eltorito-alt-boot options of --efi-boot are not
really needed here, because you only have one El Torito boot image.
The implicit -no-emul-boot of --efi-boot would have to be given explicitely
if you switch to -e.

-eltorito-alt-boot is just a spearator between the definitions of boot
images. It's harmless to pile this option up, unless it splits a boot
image from its options. I.e. this would be bad:

  -e /boot/grub/efi.img -eltorito-alt-boot -no-emul-boot

because -e would have no -no-emul-boot. This would cause the catalog
entry of the boot image to bear the mark for floppy emulation.
UEFI specs demand that it must be marked for no emulation (although
the EFI partition image is not a plain binary but rather a FAT filesystem).

> The latter seems to be for images that are not intended to be burned,
> while this one certainly could be. Is there a reason
> that it is no longer relevant?

The traditional padding is a somewhat misguided preparation for burning
onto CD media with write type Track-At-Once (TAO). I tried to explain the
real problem to the Linux SCSI people in
  https://www.spinics.net/lists/linux-scsi/msg94638.html
Having surplus bytes at the end of the CD prevents Linux from incidentially
trying to read the two unreadable final "run-out" blocks which get added
by TAO.

For users it is only important to know that any image that is too big
for CD does not need this padding, because it cannot be burnt by CD TAO.

Additional precaution is that the burn programs for CD add an own padding
by default, just out of the same misguided idea of the problem.
(My programs do it too. Who am i to change such an old tradition ?)

But there were versions of blkid which run into the TAO problem regardless
of padding. This caused my post to linux-scsi above.
I assume that they are not around any...

[Thomas Schmitt (scdbackup)]

Errata: Please read "spearator" as "separator".

[dann frazier (dannf)]

@infinity: btw, what version of xorriso is used to build official images?

[Steve Langasek (vorlon)]

On Thu, Oct 05, 2017 at 03:24:53PM -0000, dann frazier wrote:
> @infinity: btw, what version of xorriso is used to build official images?

1.4.2-4ubuntu1

[Thomas Schmitt (scdbackup)]

Hi,

at least the server ISO is made by a much older xorriso.

  xorriso -indev ubuntu-17.04-server-arm64.iso -pvd_info

says

  ...
  Preparer Id : XORRISO-1.2.4 2012.07.20.130001, LIBISOBURN-1.2.4, LIBISOFS-1.2.4, LIBBURN-1.2.4
  ...

1.4.8 will still be 4 days in Debian "unstable" before it migrates to "testing".
But the binary from
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.8.tar.gz
can be used from where it was built, without installation.
The file
  http://bazaar.launchpad.net/~dannf/debian-cd/lp1692876/view/head:/Makefile
gives me the impression that one can use it by e.g.

  export MKISOFS="$HOME"/xorriso-1.4.8./xorriso/xorriso

after having unpacked xorriso-1.4.8.tar.gz in "$HOME" and having built
it in the emerged directory "$HOME"/xorriso-1.4.8.

Have a nice day :)

Thomas

[Thomas Schmitt (scdbackup)]

Hi,

it comes to me that if you have to expect antique versions of xorriso,
then it is of interest when the newly used options became available:

  -partition_offset since 0.6.2
  -append_partition since 0.6.4
  -e since 0.6.2
  --efi-boot --interval:appended_partition_2:all:: since 1.4.4
  -e --interval:appended_partition_2:all:: since 1.4.4

Current on Ubuntu and Debian 9 is 1.4.6.

Further i now suspect that one has to add arguments " -as mkisofs" to
the MKISOFS environment variable. One may also simply replace file
/usr/bin/xorriso by the newly built "$HOME"/xorriso-1.4.8/xorriso/xorriso.
The new one will be a big binary with no special runtime dependencies.

Have a nice day :)

Thomas

[dann frazier (dannf)]

Thanks Thomas & Steve.

My takeaways are:
  - I should drop the commit "Point to the el torito catalog to the appended partition" because the version of xorriso we use (be it 1.2.4 or 1.4.2) won't support it. I actually think I'll replace it with a comment reminding us to make this transition when our build system is upgraded.

  - I should continue to omit -no-pad. While I think it is unlikely someone is going to burn and use an arm64 CD, it isn't impossible (artful server dailies are < 700MB at the moment). Certainly an argument can be made that we could explicitly drop CD (or just TAO) support, but I'll defer that to an architecture-independent discussion.

[dann frazier (dannf)]

Please consider this resubmit. I've tested it on a Cavium ThunderX CRB as both a CD and USB disk.

review: Needs Resubmitting

[Thomas Schmitt (scdbackup)]

Hi,

the commit text of 1976 is a bit misleading.
Rather than talking of "several implied options" it would be better to
explicitely mention the implied surrounding options -eltorito-alt-boot.

The comment in 1977 needs mending by prepending -e or -efi-boot
to "--interval:appended_partition_2:all::". Although it looks a bit
like an option, "--interval:..." actually is a pseudo-path which is a
parameter to option -e or -efi-boot.

--------------------------------------------------------------------

As for -no-pad, it would with current xorriso versions not take away
any effective protection against the Linux TAO CD bug, if a partition
is appended.

Due to traditional constraints, the padding is part of the claimed ISO
filesystem size. So it gets placed after the filesystem end but before
the appended partition. This way the partition gets into the role of
the exposed potential bug victim.
Whether this is bad, depends on the system which shall read the CD.
One would have to examine whether EFI has the TAO CD read-ahead bug.

The new feature of -partition_offset 16 to enable full image file size
as fileystem size of the first ISO superblock now gives the opportunity
to put the padding after the end of the partition.
But this still has to be implemented in libisofs.

For now, if you do not want to add padding by other means, your users
have to rely on the default of CD burn programs to add 300 KB of padding.
cdrskin and xorrecord use write type Session-at-Once (SAO) by default,
if the size of the input stream is known. This is normally the case with
burning of image files.
cdrecord and wodim use TAO by default. With them the default padding will
save the day.

> Certainly an argument can be made that we could explicitly drop CD
> (or just TAO) support,

The decision of the CD write type is made by the user who burns the CD
or by the user's burn program.

One would have to test the programs mentioned at
  https://help.ubuntu.com/community/BurningIsoHowto
whether they use padding or Session-at-Once by default.

The only workarounds which come to my mind for this dilemma are to append
a victim partition 3:

  dd if=/dev/zero bs=300K count=1 of=./padding_partition

  xorriso -as mkisofs \
          ...the.other.options... \
          -append_partition 3 0x00 ./padding_partition \
          /mnt/iso

or to append padding to the image file of partition 2:

  dd if=/dev/zero bs=300K count=1 >>$CDDIR/boot/grub/efi.img

before running xorriso.

Have a nice day :)

Thomas

[Thomas Schmitt (scdbackup)]

Hi,

pondering why Debian arm64 ISOs never caused a complaint about missing
padding at the image end, i find this explanation (except that arm64
might rarely be fed with CD media):

If presented on CD, DVD, or BD media, the EFI firmware will use the
System Partition image that is a data file inside the ISO.
This file is surely protected from the Linux bug by the appended partition,
which has no role when the ISO is on a CD.

So currently the new ISO layout for Ubuntu arm64 is safe.
It will become unsafe only by the future change to
  -e --interval:appended_partition_2:all::

As a consequence this fact should be mentioned in the comment added
by commit 1977. Like

    # Once we move to xorriso >= 1.4.4, we should consider changing from
    # "-e boot/grub/efi.img"
    # to
    # "-e --interval:appended_partition_2:all::"
    # This will point the El Torito catalog to the appended partition instead
    # of the in-ISO file, which will allow us to remove efi.img from the ISO
    # filesystem and recover it's space.
    #
    # But as long as we have to expect CD burn runs with write type TAO
    # it will be wise to add the traditional 300 KB of padding to the
    # EFI System Partition image before appending it as partition 2
    # and then using it as El Torito boot image by above future change.
    # This padding will prevent the old Linux TAO CD read-ahead bug.
    #
    # That bug cannot happen with the current situation because the partition
    # is not used as El Torito image and thus not read when booting from CD.

So currently you can safely add -no-pad and save 300 KB as compensation for
the waste of having two EFI System Partition images.

Have a nice day :)

Thomas

[lp:~dannf/debian-cd/lp1692876]

1974. By dann frazier on 2017-10-11

Drop xorriso parameters that have no effect

Passing "-boot-load-size 4" and "-boot-info-table" before "-eltorito-alt-boot"
has no effect. It is likely cruft cargo-culted from x86, just drop it.

Thanks to Thomas Schmitt.

1975. By dann frazier on 2017-10-11

Use '-e' instead of '--efi-boot' on the xorriso cmdline

This should have no functional change. --efi-boot includes several implied
options that we don't need with just the one el torito image. It also implies
-no-emul-boot, which we are already passing anyway (and need to keep with
the switch to -e).

1976. By dann frazier on 2017-10-11

Use '-e' instead of '--efi-boot' on the xorriso cmdline

This should have no functional change. The surrounding implicit
-eltorito-alt-boot options of --efi-boot are not needed here because we only
have one El Torito image. --efi-boot also implies -no-emul-boot, which we
were passing redundantly. With -e, -no-emul-boot needs to be passed explicitly,
so it is retained in this commit.

Thanks to Thomas Schmitt.

1977. By dann frazier on 2017-10-11

Leave a reminder to switch the el torito image to the appended partition
once we can safely assume a new enough xorriso version.

1978. By dann frazier on 2017-10-11

Add '-partition_offset 16' to xorriso parameters

Suggested by Thomas Schmitt, who describes the following benefits:

[-partition_offset 16] will yield a more conventional start of partition 1

  Device Boot Start End Sectors Size Id Type
  test.iso1 64 332111 332648 162.4M cd unknown
  test.iso2 332712 334759 2048 1M ef EFI (FAT-12/16/32)

but also will enable xorriso >= 1.4.8 to let the ISO superblock of
the device claim the range up to the end of partition 2.
So commands like `isosize` will be in sync with the image file

[dann frazier (dannf)]

Thanks Thomas. I've made the two corrections you noted. I've continued to omit any changes for padding because my immediate goal here is to get arm64 booting again, and padding is an optimization I think we can take up in a follow-on merge proposal (perhaps benefiting more architectures).

review: Needs Resubmitting

[Thomas Schmitt (scdbackup)]

Hi,

yes, let's first collect some success. :))

About the need for padding (again):
It seems safe if the EFI partition / boot image is smaller than 32 MiB.
Up to that size, the El Torito catalog is able to record the exact size
of the boot image. In this case a firmware or operating system has very few
reason to read over this size.
But beginning with 32 MiB, the catalog's 16-bit block counter field can
only state 0 or 1, which means in UEFI: "Up to the end of the medium".
At this point, a wrong medium size information from the DVD drive could
cause problems.

I did not find a way yet, to subscribe to this thread.
If problems arise, please give me a note via <email address hidden> or in
private via <email address hidden>.

Have a nice day :)

Thomas

=== modified file 'tools/boot/artful/boot-arm64'
--- tools/boot/artful/boot-arm64	2017-04-25 21:27:20 +0000
+++ tools/boot/artful/boot-arm64	2017-10-11 17:56:45 +0000
@@ -112,8 +112,15 @@
 	CASPER_INITRD="/casper/initrd$(initrd_suffix "$CDDIR/casper/filesystem.initrd-$FLAVOUR")"
 	mv $CDDIR/casper/filesystem.initrd-$FLAVOUR "$CDDIR$CASPER_INITRD"
     fi
-    echo -n "-J -l -c boot/boot.cat -boot-load-size 4 -boot-info-table " >> $N.mkisofs_opts
-    echo -n "-eltorito-alt-boot --efi-boot boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
+    echo -n "-J -l -c boot/boot.cat -partition_offset 16 " >> $N.mkisofs_opts
+    # Once we move to xorriso >= 1.4.4, we should consider changing from
+    #  "-e boot/grub/efi.img"
+    #    to
+    #  "-e --interval:appended_partition_2:all::"
+    # This will point the el torito catalog to the appended partition instead
+    # of the in-ISO file, which will allow us to remove efi.img from the ISO
+    # filesystem and recover it's space.
+    echo -n "-append_partition 2 0xef $CDDIR/boot/grub/efi.img -e boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
 fi
 
 #install_languages $CDDIR

=== modified file 'tools/boot/xenial/boot-arm64'
--- tools/boot/xenial/boot-arm64	2017-02-21 04:29:37 +0000
+++ tools/boot/xenial/boot-arm64	2017-10-11 17:56:45 +0000
@@ -112,8 +112,15 @@
 	CASPER_INITRD="/casper/initrd$(initrd_suffix "$CDDIR/casper/filesystem.initrd-$FLAVOUR")"
 	mv $CDDIR/casper/filesystem.initrd-$FLAVOUR "$CDDIR$CASPER_INITRD"
     fi
-    echo -n "-J -l -c boot/boot.cat -boot-load-size 4 -boot-info-table " >> $N.mkisofs_opts
-    echo -n "-eltorito-alt-boot --efi-boot boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
+    echo -n "-J -l -c boot/boot.cat -partition_offset 16 " >> $N.mkisofs_opts
+    # Once we move to xorriso >= 1.4.4, we should consider changing from
+    #  "-e boot/grub/efi.img"
+    #    to
+    #  "-e --interval:appended_partition_2:all::"
+    # This will point the el torito catalog to the appended partition instead
+    # of the in-ISO file, which will allow us to remove efi.img from the ISO
+    # filesystem and recover it's space.
+    echo -n "-append_partition 2 0xef $CDDIR/boot/grub/efi.img -e boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
 fi
 
 #install_languages $CDDIR

=== modified file 'tools/boot/yakkety/boot-arm64'
--- tools/boot/yakkety/boot-arm64	2017-02-21 04:29:37 +0000
+++ tools/boot/yakkety/boot-arm64	2017-10-11 17:56:45 +0000
@@ -112,8 +112,15 @@
 	CASPER_INITRD="/casper/initrd$(initrd_suffix "$CDDIR/casper/filesystem.initrd-$FLAVOUR")"
 	mv $CDDIR/casper/filesystem.initrd-$FLAVOUR "$CDDIR$CASPER_INITRD"
     fi
-    echo -n "-J -l -c boot/boot.cat -boot-load-size 4 -boot-info-table " >> $N.mkisofs_opts
-    echo -n "-eltorito-alt-boot --efi-boot boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
+    echo -n "-J -l -c boot/boot.cat -partition_offset 16 " >> $N.mkisofs_opts
+    # Once we move to xorriso >= 1.4.4, we should consider changing from
+    #  "-e boot/grub/efi.img"
+    #    to
+    #  "-e --interval:appended_partition_2:all::"
+    # This will point the el torito catalog to the appended partition instead
+    # of the in-ISO file, which will allow us to remove efi.img from the ISO
+    # filesystem and recover it's space.
+    echo -n "-append_partition 2 0xef $CDDIR/boot/grub/efi.img -e boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
 fi
 
 #install_languages $CDDIR

=== modified file 'tools/boot/zesty/boot-arm64'
--- tools/boot/zesty/boot-arm64	2017-02-21 04:29:37 +0000
+++ tools/boot/zesty/boot-arm64	2017-10-11 17:56:45 +0000
@@ -112,8 +112,15 @@
 	CASPER_INITRD="/casper/initrd$(initrd_suffix "$CDDIR/casper/filesystem.initrd-$FLAVOUR")"
 	mv $CDDIR/casper/filesystem.initrd-$FLAVOUR "$CDDIR$CASPER_INITRD"
     fi
-    echo -n "-J -l -c boot/boot.cat -boot-load-size 4 -boot-info-table " >> $N.mkisofs_opts
-    echo -n "-eltorito-alt-boot --efi-boot boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
+    echo -n "-J -l -c boot/boot.cat -partition_offset 16 " >> $N.mkisofs_opts
+    # Once we move to xorriso >= 1.4.4, we should consider changing from
+    #  "-e boot/grub/efi.img"
+    #    to
+    #  "-e --interval:appended_partition_2:all::"
+    # This will point the el torito catalog to the appended partition instead
+    # of the in-ISO file, which will allow us to remove efi.img from the ISO
+    # filesystem and recover it's space.
+    echo -n "-append_partition 2 0xef $CDDIR/boot/grub/efi.img -e boot/grub/efi.img -no-emul-boot " >> $N.mkisofs_opts
 fi
 
 #install_languages $CDDIR