Warum kann mein benutzerdefiniertes ISO nicht in EFI booten?

Warum kann mein benutzerdefiniertes ISO nicht in EFI booten?

Ich erstelle ein benutzerdefiniertes ISO mit xorriso im mkisofs-Modus. Der Build scheint korrekt zu sein. Bei der anschließenden Überprüfung des ISO werden 2 Boot-Images angezeigt (1 BIOS, 2 UEFI). Beim Booten des ISO von qemu mit der OVMF-Firmware werden jedoch keine bootfähigen Medien gefunden.

Wenn ich in QEMU genau denselben Bootvorgang versuche, aber ein sauber heruntergeladenes Ubuntu 16.04-Server-ISO verwende, bootet es ohne Probleme.

Wenn ich das BIOS (nicht UEFI) verwende, booten beide problemlos.

xorriso-Befehl:

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/

Die Einzelheiten der Untersuchung der 2 ISO (Ubuntu und meine benutzerdefinierte erstellte) mit xorriso -report_el_torito plainund cmdsind im folgenden Gisthttps://gist.github.com/deitch/e069268f92402d6a2b1c7e060ddba622

Antwort1

Vielen Dank fürs Fliegen xorriso.

Das Problem liegt in der Image-Datei, die Sie von xorriso als EFI-Systempartition markieren ließen. Es soll ein FAT-Dateisystem-Image sein, das eine Binärdatei namens /EFI/BOOT/BOOTX64.EFI(oder ... /BOOTIA32.EFIfür 32-Bit x86) und möglicherweise weitere Dateien enthält. Mounten Sie die Datei /boot/grub/efi.img vom Ubuntu-ISO, um mehr über ihren Inhalt zu erfahren.

Die von Ubuntu und anderen verwendeten FAT-Dateisysteme werden wahrscheinlich vom GRUB2-Programm grub-mkimage erstellt. Die ISOLINUX/SYSLINUX EFI-Software kann nicht verwendet werden, da sie beim Erkennen eines CD-ROM-Geräts abstürzt.

Eine recht bequeme Möglichkeit, ein bootfähiges ISO zu erhalten, ist das Programm grub-mkrescue. Wenn GRUB2 für BIOS und EFI konfiguriert ist (z. B. durch die Installation der Binärpakete grub-pc, grub-efi-amd64, und grub-efi-ia32), grub-mkrescue wird ein ISO erstellt, das im BIOS und EFI von 32-Bit- und 64-Bit-x86-Maschinen bootet: El Torito-Bootimages für BIOS und EFI, EFI-Image mit BOOTX64.EFIund BOOTIA32.EFI, MBR für BIOS von der Festplatte, GPT für EFI von der Festplatte.

Antwort2

Dies kann ganz einfach folgendermaßen geschehen:

Hängen Sie efi.img(von Ubuntu ISO unter boot/grub/efi.img) an Ihr ISO an und es wird in jedem System gebootet.

cat efi.img >> youriso.iso

Danach funktioniert Ihr ISO sowohl als CD-ROM als auch als USB-Stick. :D

Antwort3

Ich weiß sicherlich nicht so viel über xorriso wie Thomas Schmitt, aber ich verwende Folgendes, um ein Nur-EFI-ISO zu erstellen.

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

Wobei $ISO_NEW der Name der Ausgabe-ISO und $DIR_EXTRACT die gehackte Version xorriso ... -extract / $DIR_EXTRACT, in diesem Fall, der Debian 10-Version ist.

Fast alle Beispiele, die ich gesehen habe, verwenden einen hybriden MBR/EFI, der flexibler ist, aber auch die Bootloader-Schritte komplizierter macht. Dies istNUREFI, unter Verwendung des VFAT-Image in efi.img. Ich verwende das generierte ISO zusammen mit dem OVMF-Bootloader, um ein benutzerdefiniertes, voreingestelltes Debian-Installationsprogramm auszuführen und ein $DISKImage zu erstellen, das ich für die QEMU-Codierung verwende.

Führen Sie „install“ aus, um die qcow2-Diskette zu erstellen:

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

Konfigurieren und führen Sie einen Regressionstest der Festplatte über SSH durch.

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

Für die Entwicklung führe ich QEMU unter gdb mit einer ähnlichen Befehlszeile aus, jedoch mit mehr CPUs und ohne Headless -nographic(und -Sum es vorher einzurichten, gdb-Quelldateien zu laden usw. cpu_exec).

Und schließlich sehen Sie hier, wie das installierte $DISK in der VM aussieht. Beachten Sie die EFI-Systempartition (ESP) unter /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> 

verwandte Informationen