Hi,
René Rebe wrote:
> [xorriso -as mkisofs arguments]
> should that be reversed, or am I missing something else?
Option --protective-msdos-label gets overridden by -partition_offset 16,
which is beneficial. So you could as well omit it.
Otherwise the xorrisofs option set looks ok.
fdisk -l should report about the result something like
Device Boot Start End Sectors Size Id Type
test.iso1 * 64 259 196 98K 83 Linux
test.iso2 260 6019 5760 2.8M ef EFI (FAT-12/16/32)
(with larger payload in partition 1 and other size in partition 2, i assume)
OVMF is supposed to recognize the EFI partition and act on its content.
It should go by partition table if the ISO is presented as virtual hard
disk. With a virtual CD-ROM it should go by El Torito catalog.
xorriso -indev test.iso -report_el_torito plain
should report
...
Boot record : El Torito , MBR grub2-mbr cyl-align-off
...
El Torito catalog : 49 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 50
El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 65
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table grub2-boot-info
El Torito img blks : 2 1440
(with different decimal numbers except "1", "2" and "4")
LBA is counted in blocks of 2048 bytes. 4 * 65 = 260.
Ldsiz is counted in 512-byte blocks. (Wonders of El Torito ...)
> Qemu/OVMF does not like to boot from that ISO, yet :-/
If partition table and El Torito catalog are as expected, then the problem
must be inside the VFAT filesystem efi.img.
Roughly replaying your ISO production process:
I slaughtered a grub-mkrescue ISO for functional boot images and MBR
code. Then i packed up "test.iso" as you do, but without much payload.
Above example listings stem from that ISO.
The following runs yield a "grub rescue>" prompt for me (on old Debian as
host):
qemu-system-x86_64 -enable-kvm -m 1024 -bios /usr/share/ovmf/OVMF.fd \
-hda ./test.iso
qemu-system-x86_64 -enable-kvm -m 1024 -bios /usr/share/ovmf/OVMF.fd \
-cdrom ./test.iso
Without -bios .../OVMF.fd, i get the prompt too.
Now i verify that it is really the boot equipment which causes the prompt:
# Kill MBR partition table
cp test.iso test_copy.iso
dd if=/dev/zero conv=notrunc bs=1 seek=446 count=64 of=test_copy.iso
This does not boot by OVMF from -hda any more. It rather shows an UEFI
"Shell>" prompt.
Nevertheless it is still booting by OVMF from -cdrom.
So next:
# Death to the El Torito boot catalog (xorriso reports its LBA as 49)
dd if=dev/zero conv=notrunc bs=2048 seek=49 count=1 of=test_copy.iso
Now neither -hda nor -cdrom yield a GRUB prompt on OVMF.
SeaBIOS still boots from -hda but not from -cdrom.
# Off with the MBR x86 boot code
dd if=/dev/zero conv=notrunc bs=1 count=446 of=test_copy.iso
Now nothing boots any more.
(My virtual firmwares show a stunning obedience to the specs.
One inormally has to expect that -hda boots via El Torito or -cdrom
via MBR.)
-----------------------------------------------------------------------
TLDR-warning.
Following are only some explanations of what the options cause xorriso
to do:
> It looks like I ended up needing -eltorito-alt-boot -no-emul-boot in
> between the x86-mbr and the above hybrid stuff, does that make sense?
-eltorito-alt-boot is the separator between the add-on options of the
El Torito (i.e. CD/DVD/BD) boot image for BIOS (main option -b) and the
add-on options of the El Torito boot image for EFI (-e).
The Debian ISO production already has it. I should have mentioned it here.
-no-emul-boot is an add-on option which says that the boot image does not
emulate floppy or hard disk. It is needed for both GRUB boot images.
The image for BIOS is a x86 program, the image for EFI is a VFAT filesystem.
Your current option set says:
> -b boot/grub/i386-pc/eltorito.img -no-emul-boot
> -boot-load-size 4 -boot-info-table --grub2-boot-info
The El Torito boot image for BIOS is x86 program eltorito.img, of which
BIOS shall load the first 4 * 512 bytes and execute them.
By -boot-info-table xorriso writes the file's ISO block address into this
range of eltorito.img, which the code uses at boot time to find and load
the rest of the program.
Another kind of such exposed filesystem entrails is written by
--grub2-boot-info.
> --protective-msdos-label
> -partition_offset 16
This is contradicting.
--protective-msdos-label is a habit of grub-mkrescue and prevents partition
number 1 from being mountable. Reason is that partition editors hate
partition at block 0.
-partition_offset 16 causes a second superblock and directory tree which can
be mounted by partition 1 which begins at 512-byte block 64. Clearly the
more useful way to please partition editors.
> --grub2-mbr $build_root/usr/lib*/grub/i386-pc/boot_hybrid.img
This copies and adjusts MBR x86 code for booting via BIOS from USB stick.
> -append_partition 2 0xef $isofsdir/efi.img
This appends the prepared VFAT filesystem image to the end of the filesystem.
It is not represented as file in the ISO. The ISO 9600 superblock in
partition 1 will not claim its data range. But the ISO 9660 superblock at
offset 0 will claim both partitions as part of its range.
of the ISO 9660 filesystem range.
> -eltorito-alt-boot -no-emul-boot
> -e --interval:appended_partition_2:all::
This causes xorriso to mark in the El Torito boot catalog the appended
partition's data range as boot image for EFI.
> -iso_mbr_part_type 0x83
The mountable ISO partition gets MBR partition table type 0x83 "Linux".
-----------------------------------------------------------------------
Have a nice day :)
Thomas
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
