Hi,
René Rebe wrote: > I wanted to add native EFI support next, too. There are several variations to let xorriso add an EFI System Partition. All refer the EFI partiton by partition table and by El Torito catalog. The mainstream uses Matthew J. Garrett's isohybrid layout with EFI partition 2 inside ISO partition 1. It happens to work, but is abominable to partition editors. Actually the partition tables are MBR and APM, but there is also a probably useless GPT prescribed in this layout. https://www.syslinux.org/wiki/index.php?title=User:Ady/Layouts_of_bootable_ISO_9660_filesystem_images&action=render#BIOS_and_UEFI_hybrid_with_nested_MBR_partitions.2C_GPT.2C_APM.2FHFS.2B grub-mkrescue sacrifices the mountable ISO partition in favor of a specs compliant disjoint set of partitions. Partition table is GPT. https://www.syslinux.org/wiki/index.php?title=User:Ady/Layouts_of_bootable_ISO_9660_filesystem_images&action=render#BIOS_and_UEFI_hybrid_with_GPT_and_APM.2FHFS.2B.2C_by_xorriso_underneath_grub-mkrescue My favorite is what Knoppix 8.1 has: An appended MBR partition after the ISO filesystem partition with partition offset. This is well accepted by partition editors. By the partition offset, the first ISO superblock is outside partition 1 and thus can claim the whole image size including EFI partition 2 and the additional growable ReiserFS partition 3. So /sbin/isosize can tell the correct image size as with the other two layouts. https://www.syslinux.org/wiki/index.php?title=User:Ady/Layouts_of_bootable_ISO_9660_filesystem_images&action=render#BIOS_and_UEFI_hybrid_with_neat_MBR_partitions.2C_and_partition_offset_by_xorriso You may also use xorriso to get proposals from existing ISOs for the boot related xorrisofs options: xorriso -indev $iso_to_inspect -report_system_area as_mkisofs See also https://wiki.debian.org/RepackBootableISO#What_to_do_if_no_file_.2F.disk.2Fmkisofs_exists > Do you happen to know Sgi MIPS Arcs details? Only what i learned from Debian and its genisoimage code. xorriso -indev debian-7.4.0-mips-netinst.iso -report_system_area as_mkisofs proposes -V 'Debian 7.4.0 mips 1' --modification-date='2014020817415200' -mips-boot '/install/r4k-ip22-boot.img' -G --interval:local_fs:0s-15s::'debian-7.4.0-mips-netinst.iso' The first two are only to give the new ISO the same individual ids as the original. Some boot processes look for those ids to find the device with the ISO filesystem. (Debian's does not.) Option -mips-boot is specific for MIPS Big Endian, but i do not know how Debian made the file /install/r4k-ip22-boot.img. Option -G and its cryptic argument copy 32 KiB from the start of the original ISO and put them to the start of the new ISO. (You could use dd to cut out those blocks, store them as small file on your disk, and use it with option -G. The xorrisofs argument "--interval:..." does similar.) Actually only the first 512 bytes are non-zero. My cheat sheet https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt has a chapter about "MIPS Volume Header for MIPS Big Endian, e.g. SGI Indigo2." which hopefully correctly explains their meaning. (All is hearsay ...) With current Debian "mips64el", there is no boot equipment at all. Have a nice day :) Thomas ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
