I want to create an ISO image that boots ONLY on UEFI environments. I've managed to create images that boot on BIOS systems, but I can't figure out how to create an image that works only on UEFI.

I've read xorriso's manual, and fiddled a lot with its options, but had no luck.

I need that when such image gets flashed into a USB stick, it boots only on UEFI, and not in MBR-based BIOS.

  • There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited? – jdv Jan 17 at 20:34
  • 2
    Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/… – oldfred Jan 17 at 20:37
  • 4
    Possible duplicate of How to create UEFI-only bootable USB live media? – user535733 Jan 17 at 22:50
  • No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI. – Luis Lavaire Jan 18 at 4:28
  • Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path. – Thomas Schmitt Jan 18 at 6:15

A good guide is this Debian web page.

An image that boots only on UEFI can be created with xorriso like this:

xorriso -as mkisofs \
    -iso-level 3 \
    -r -V <ISO_LABEL> \
    -J -joliet-long \
    -append_partition 2 0xef <BOOT_IMG> \
    -partition_cyl_align all \
    -o <OUTPUT_IMAGE> \

The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:

BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img

mkdir -p $(dirname $BOOT_IMG)

truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mkdir -p $BOOT_IMG_DATA/efi/boot

grub-mkimage \
    -C xz \
    -O x86_64-efi \
    -p /boot/grub \
    -o $BOOT_IMG_DATA/efi/boot/bootx64.efi \
    boot linux search normal configfile \
    part_gpt btrfs ext2 fat iso9660 loopback \
    test keystatus gfxmenu regexp probe \
    efi_gop efi_uga all_video gfxterm font \
    echo read ls cat png jpeg halt reboot


That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.

This answer was based on a coment by @ThomasSchmitt.

  • 1
    The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.) – Thomas Schmitt Jan 22 at 12:31
  • 1
    After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared. – Thomas Schmitt Jan 22 at 12:40
  • 1
    Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range. – Thomas Schmitt Jan 23 at 15:08
  • Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag -partition_offset 16, the output of fdisk -l <OUTPUT_IMAGE> listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account? – Luis Lavaire Jan 23 at 17:22
  • Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef. – Thomas Schmitt Jan 23 at 18:36

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.