Hi, > xorriso -as mkisofs -r -J -b isolinux.bin -c boot.cat \ > -no-emul-boot -boot-load-size 4 -boot-info-table \ > -eltorito-alt-boot \ > --efi-boot boot/grub/efi.img -no-emul-boot \ > -o $(TEMP_MINIISO) $(TEMP_CD_TREE); \
I did not guess too bad with my repacking experiment. But this does not explain how the empty FAT partition got to the end of mini.iso I see in http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg#n347 geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO) So obviously the appended partition was not intended for EFI but for additional firmware. Now if mini.iso gets GPT, then http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/geniso_hybrid_plus_firmware_partition should add its partition to GPT too. At its end, it uses fdisk to manipulate the MBR partition table. Number 2 would have to become 3 then, because slot 2 is already occupied by /boot/grub/efi.img. I guess that gdisk can do similar for GPT. Problem is that the GPT backup block needs to be moved after the end of the partition data which was appended in line 37: cat "$firmware_volume_file" >> "$iso" I dimly remember that gdisk has a menu item for moving the backup GPT and/or for re-creating the backup GPT. The backup GPT would actually have to be re-located whenever the ISO image gets copied onto a disk device. It might be that gdisk or other partition editors go on strike when they see the nested partitions. In this case, we might need to write MBR and GPT slots on byte level. (A re-write to geniso_hybrid_plus_firmware_partition.c would be a good idea then. Byte manipulation in shell is cumbersome.) It is a bad idea to apply the SYSLINUX program "isohybrid" to an ISO which was equipped with advanced isohybrid by xorriso. So one should delete line 26: isohybrid -h "$heads" -s "$sectors" "$iso" > I guess -e is short for --efi-boot? --efi-boot XYZ does a bit more: -eltorito-alt-boot -e XYX -no-emul-boot -eltorito-alt-boot Since i propose to apply -isohybrid-gpt-basdat, one would have to switch to -e . E.g.: - -eltorito-alt-boot \ - --efi-boot boot/grub/efi.img -no-emul-boot \ + -eltorito-alt-boot \ + -e boot/grub/efi.img \ + -no-emul-boot -isohybrid-gpt-basdat \ -e is quite like -b, including the inappropriate default to mark the boot image in El Torito as emulated floppy disk. Therefore option -no-emul-boot must be given. > I don't suppose I can tempt you into sending a patch against the above > git repo, can I? ;-) Seems we are not done with development yet. There is the problem that i cannot easily test because i have no EFI and not even a contemporary Debian. If an authorized developer can set up a suitable environment for production of mini.iso, i will help to adapt the scripts. We will have to make decisions. E.g. whether to keep a BIOS-only version of mini.iso and thus cannot hardcode the partition number in geniso_hybrid_plus_firmware_partition. Some experience with gdisk would be helpful. (I guess my Debian 6 test system can give me hints.) --------------------------------------------------------- Alternatively one could really copy the directories and boot program from /boot/grub/efi.img into the appended partition and give it the type 0xef. Having no GPT would avoid problems with the appended partition. But it might be that some EFI implementations will not recognize the MBR partition and insist in GPT. Only tests can tell. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6610543333846588...@scdbackup.webframe.org
