为什么我的自定义构建 iso 无法在 EFI 中启动?

为什么我的自定义构建 iso 无法在 EFI 中启动?

我正在 mkisofs 模式下使用 xorriso 构建自定义 iso。构建似乎是正确的,随后检查 iso 显示 2 个启动映像(1 个 BIOS、2 个 UEFI),但使用 OVMF 固件从 qemu 启动到 ISO 无法找到任何可启动媒体。

如果我在 qemu 中尝试完全相同的启动,但使用干净下载的 ubuntu 16.04 服务器 iso,则启动不会出现问题。

如果我使用 BIOS(不是 UEFI),两者都能正常启动。

xorriso 命令:

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/

xorriso -report_el_torito plain使用和检查 2 个 iso(ubuntu 和我定制的一个)的详细信息cmd如下:https://gist.github.com/deitch/e069268f92402d6a2b1c7e060ddba622

答案1

谢谢你飞翔xorriso

问题出在您让 xorriso 标记为 EFI 系统分区的映像文件中。它应该是一个 FAT 文件系统映像,其中包含一个名为/EFI/BOOT/BOOTX64.EFI(或 .../BOOTIA32.EFI对于 32 位 x86)的二进制文件以及可能的其他文件。从 Ubuntu ISO 挂载文件 /boot/grub/efi.img 以了解其内容。

Ubuntu 和其他操作系统使用的 FAT 文件系统可能是由 GRUB2 程序 grub-mkimage 生成的。 ISOLINUX/SYSLINUX EFI 软件无法使用,因为它在看到 CD-ROM 设备时会跳出。

获取可启动 ISO 的一个非常方便的方法是编程grub-mkrescue。如果 GRUB2 配置为 BIOS 和 EFI(例如,通过安装二进制包grub-pcgrub-efi-amd64grub-efi-ia32),那么grub-mkrescue 将生成一个在 32 位和 64 位 x86 机器的 BIOS 和 EFI 上启动的 ISO: 用于 BIOS 和 EFI 的 El Torito 启动映像,EFI 映像具有 BOOTX64.EFI以及BOOTIA32.EFI,MBR 用于硬盘中的 BIOS,GPT 用于硬盘中的 EFI。

答案2

一个非常简单的方法是:

将(来自 boot/grub/efi.img 处的 ubuntu ISO)附加efi.img到您的 ISO,它将在每个系统中启动。

cat efi.img >> youriso.iso

之后,您的 ISO 将同时作为 CDROM 和 USB 随身碟使用。 :D

答案3

我当然不像 Thomas Schmitt 那样了解 xorriso,但我使用以下内容来创建仅 EFI 的 ISO。

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

xorriso ... -extract / $DIR_EXTRACT其中 $ISO_NEW 是输出 ISO 的名称,$DIR_EXTRACT 是从本例中的 Debian 10 版本中破解的。

我见过的几乎所有示例都使用混合 MBR/EFI,这更灵活,但也使引导加载程序步骤变得复杂。这是仅有的EFI,使用efi.img.我使用生成的 ISO 以及 OVMF 引导加载程序来运行自定义预置 debian 安装程序,以创建$DISK用于 QEMU 编码的映像。

运行 install 创建 qcow2 磁盘:

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

通过 SSH 配置和回归测试 DISK。

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

对于开发,我使用类似的命令行在 gdb 下运行 QEMU,但具有更多 CPU 和无头-nographic(并-S在之前进行设置、加载 gdb 源文件等cpu_exec。)

最后,这是虚拟机内安装的 $DISK 的样子。请注意 EFI 系统分区 (ESP),位于/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> 

相关内容