8

I am building a custom iso using xorriso in mkisofs mode. The build seems correct, inspecting the iso afterwards shows 2 boot images (1 BIOS, 2 UEFI), yet booting to the ISO from qemu using the OVMF firmware fails to find any bootable media.

If I try the exact same boot in qemu but using a clean downloaded ubuntu 16.04 server iso, it boots without a problem.

If I use BIOS (not UEFI), both boot just fine.

xorriso command:

xorriso -as mkisofs \
   -l -J -R -V version \
   -no-emul-boot -boot-load-size 4 -boot-info-table \
   -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat \
   -isohybrid-mbr isohhdpfx.bin \
   -eltorito-alt-boot -e EFI/BOOT/BOOTX64.EFI -no-emul-boot \
   -isohybrid-gpt-basdat \
   -o testos.iso ./cddir/

The details of examining the 2 iso (ubuntu and my custom built one) with xorriso -report_el_torito plain and cmd are in the following gist https://gist.github.com/deitch/e069268f92402d6a2b1c7e060ddba622

1
  • The program mkisofs does not have an option called -e. If you like to create a EFI boot, you would need to use -eltorito-platform EFI. .... Just in case you believe that xorriso implents the mkisofs behavior. There are more deviations, like the built in -findand UDF support in mkisofs that is missing from xorrise.
    – schily
    Commented Jul 9, 2018 at 11:54

3 Answers 3

10

Thank you for flying xorriso.

The problem is in the image file which you let xorriso mark as EFI System Partition. It is supposed to be a FAT filesystem image which contains a binary file named /EFI/BOOT/BOOTX64.EFI (or .../BOOTIA32.EFI for 32 bit x86) plus possibly other files. Mount the file /boot/grub/efi.img from the Ubuntu ISO for learning about its content.

The FAT filesystems used by Ubuntu and others are probably produced by GRUB2 program grub-mkimage. ISOLINUX/SYSLINUX EFI software cannot be used because it bails out when seeing a CD-ROM device.

A quite convenient way to get a bootable ISO is program grub-mkrescue. If GRUB2 is configured for BIOS and EFI (e.g. by installing binary packages grub-pc, grub-efi-amd64, and grub-efi-ia32) then grub-mkrescue will produce an ISO which boots on BIOS and EFI of 32 bit and 64 bit x86 machines: El Torito boot images for BIOS and EFI, EFI image having BOOTX64.EFI and BOOTIA32.EFI, MBR for BIOS from hard disk, GPT for EFI from hard disk.

4
  • And I knew it! I knew it had to be not the EFI file, but the EFI file bound up in a single file vfat img... and completely forgot. Thank you, @ThomasSchmit!
    – deitch
    Commented May 18, 2016 at 8:11
  • And another problem; kernel options not being passed. They really did make this whole thing too hard! See unix.stackexchange.com/questions/283994/…
    – deitch
    Commented May 18, 2016 at 17:29
  • @GAD3R thanks for the updates. grub-mkrescue isn't relevant here, since I am working on a custom install iso.
    – deitch
    Commented May 18, 2016 at 17:30
  • 1
    FWIW, the kernel options was a grub2 bug.
    – deitch
    Commented Jun 3, 2016 at 9:02
0

A very easy way to do it is this:

Append efi.img (from ubuntu ISO at boot/grub/efi.img) to your ISO and it will boot in every system.

cat efi.img >> youriso.iso

After that your ISO will work both as cdrom and as USB pendrive. :D

7
  • Seriously? It cannot be that simple. Why would I need to use xorriso with the complex options?
    – deitch
    Commented Nov 30, 2016 at 8:57
  • did you try it?!
    – Zibri
    Commented Dec 27, 2016 at 11:58
  • I didn't have the chance, but I will. It still boggles my mind that it can be that simple.
    – deitch
    Commented Dec 31, 2016 at 16:54
  • So is the simple method working ?
    – Overmind
    Commented Feb 1, 2017 at 12:22
  • 1
    This answer doesn't answer the question at all; it doesn't wrap up a custom directory and makes it into a bootable ISO. Commented Dec 13, 2020 at 14:57
0

I certainly don't know as much about xorriso as Thomas Schmitt but I use the following to create an EFI-only ISO.

xorriso -as mkisofs \
    -V 'deb10.5.0 preseed amd64 efi' \
    -e boot/grub/efi.img \
    -no-emul-boot \
    -o $ISO_NEW $DIR_EXTRACT

Where $ISO_NEW is the name of the output ISO and $DIR_EXTRACT is the hacked-up xorriso ... -extract / $DIR_EXTRACT from, in this case, Debian 10 release.

Almost all the examples I've seen use a hybrid MBR/EFI, which is more flexible but also complicates the bootloader steps. This is ONLY EFI, using the VFAT image in efi.img. I use the generated ISO, coupled with the OVMF bootloader, to run a custom preseeded debian installer to create a $DISK image I use for QEMU coding.

Run install to create the qcow2 disk:

   MACHOVMF="-machine q35,firmware=/usr/share/ovmf/OVMF.fd"
   $Q_P -m 4096 $MACHOVMF -hda $DISK -cdrom $ISO_NEW -vga std -monitor stdio

Configure and regression test the DISK via SSH.

   NET_Q35="-nic user,hostfwd=tcp::10022-:22"
   $Q_P -m 4096 $MACHOVMF -hda $DISK $NET_Q35 -vga std -monitor stdio

For development I run QEMU under gdb using a similar commandline but with more CPUs and headless -nographic (and -S to set up, load gdb source files, etc. before cpu_exec.)

And, finally, here's what the installed $DISK looks like inside the VM. Notice the EFI System Partition (ESP) at /boot/efi:

q35efi-2:17> df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             2004028       0   2004028   0% /dev
tmpfs             403768    5420    398348   2% /run
/dev/vda2        3546736 1515520   1831336  46% /
tmpfs            2018840       0   2018840   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            2018840       0   2018840   0% /sys/fs/cgroup
/dev/vda1         523248    5228    518020   1% /boot/efi
tmpfs             403768       0    403768   0% /run/user/1000
q35efi-2:18> blkid
/dev/vda1: UUID="DB4A-1458" TYPE="vfat" PARTUUID="7bac2a49-d394-444f-b4f7-7c822b842023"
/dev/vda2: UUID="caada636-4214-4c13-98eb-74367c1c380c" TYPE="ext4" PARTUUID="40d7e26a-1273-4af7-beb9-3ca3647a0dc5"
/dev/vda3: UUID="6d427317-3434-4425-a057-a987e847f0d2" TYPE="swap" PARTUUID="4d44decf-5237-4e81-8892-77e5e9e97a70"
q35efi-2:19> efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0006,0000,0001,0003,0004,0005,0002
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00005     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(2,65535,0)N.....YM....R,Y.
Boot0002* UEFI Misc Device  PciRoot(0x0)/Pci(0x3,0x0)N.....YM....R,Y.
Boot0003* UEFI PXEv4 (MAC:525400123456) PciRoot(0x0)/Pci(0x2,0x0)/MAC(525400123456,1)N.....YM....R,Y.
Boot0004* UEFI HTTPv4 (MAC:525400123456)    PciRoot(0x0)/Pci(0x2,0x0)/MAC(525400123456,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.....YM....R,Y.
Boot0005* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* debian    HD(1,GPT,7bac2a49-d394-444f-b4f7-7c822b842023,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
q35efi-2:20> 

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .