2

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.

Luis Lavaire
  • 161
  • There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited? –  Jan 17 '19 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. http://askubuntu.com/questions/395879/how-to-create-uefi-only-bootable-usb-live-media – oldfred Jan 17 '19 at 20:37
  • 4
    Possible duplicate of How to create UEFI-only bootable USB live media? – user535733 Jan 17 '19 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 '19 at 04:28
  • Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: https://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 '19 at 06:15
  • Why do you want this? - But I guess you can do it by {removing/never creating} the BIOS bootloader at the head of the iso file without removing the partition table (so that the EFI system partition will still be there and detected by the UEFI system). - By the way, is it necessary to have an iso file (do you want it to boot from a DVD drive), or is it enough with an image file to be cloned to a USB pendrive or memory card? – sudodus Jan 18 '19 at 07:30
  • @ThomasSchmitt, your answer worked perfectly. Thank you very much for your valuable help. Could you post your answer so I can mark it as accepted? – Luis Lavaire Jan 20 '19 at 06:09
  • @sudodus I want this to create the ISO image for a distribution I work on. We won't support BIOS, so we want to remove any support for it (BIOS) from our image. – Luis Lavaire Jan 20 '19 at 06:11
  • Sorry, as said the Captcha test does not work with my browser. So i am treated as a robot. Thank you Google. I hope Stack Overflow gets some fat money for letting them guard the door. (I like this little Q&A empire and several times found good advise here.) So please post your solution as answer here. Maybe i can add some hopefully useful remarks. – Thomas Schmitt Jan 20 '19 at 11:33
  • What a shame, @ThomasSchmitt. Anyway, thank you very much. I'll add the answer. – Luis Lavaire Jan 21 '19 at 19:22

1 Answers1

2

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> \
    <ISO_DIRECTORY>

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
mount $BOOT_IMG $BOOT_IMG_DATA
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

umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA

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.

Luis Lavaire
  • 161
  • 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 '19 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 '19 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 '19 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 '19 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 https://en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef. – Thomas Schmitt Jan 23 '19 at 18:36
  • It comes to me that EFI implementations have been reported on grub-devel mailing list which insist in seeing one MBR partition with boot/active flag. Option --mbr-force-bootable will attribute it to your partition 1. (Since xorriso-1.4.4) – Thomas Schmitt Jan 23 '19 at 19:10