Hi, Pete Batard wrote: > Debian does not use an efi.img.
Oh it does with ISOs for i386 and amd64. There is a data file in the ISO filesystem named /boot/grub/efi.img advertised as MBR partition of type 0xEF and as El Torito boot image for EFI: $ xorriso -indev debian-11.5.0-amd64-netinst.iso -report_system_area plain -report_el_torito plain ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 782336 MBR partition : 2 0x00 0xef 4064 5184 MBR partition path : 2 /boot/grub/efi.img ... El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2312 El Torito boot img : 2 UEFI y none 0x0000 0x00 5184 1016 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img But Debian is nice by having in the ISO filesystem a copy of the file tree in the FAT filesystem of the EFI partition. # mount debian-11.5.0-amd64-netinst.iso /mnt/iso ... # mount /mnt/iso/boot/grub/efi.img /mnt/fat $ (cd /mnt/fat ; find . -type f -exec ls -ld '{}' ';') -rwxr-xr-x 1 root root 934240 Sep 10 2022 ./efi/boot/bootx64.efi -rwxr-xr-x 1 root root 1684864 Sep 10 2022 ./efi/boot/grubx64.efi -rwxr-xr-x 1 root root 101 Sep 10 2022 ./efi/debian/grub.cfg $ (cd /mnt/iso ; find ./EFI -type f -exec ls -ld '{}' ';') -r--r--r-- 1 root root 934240 Sep 10 2022 ./EFI/boot/bootx64.efi -r--r--r-- 1 root root 1684864 Sep 10 2022 ./EFI/boot/grubx64.efi -r--r--r-- 1 root root 101 Sep 10 2022 ./EFI/debian/grub.cfg The differences in the paths become insignificant when copying to FAT. The tests results indicate that the lack of x-permissions with the ISO files is not an issue either. In the arm64 ISOs the /EFI tree is present three times. Once as appended MBR partition 2, once as FAT image file /boot/grub/efi.img in the ISO which serves as El Torito boot image, and again as unpacked /EFI tree in the ISO. (xorriso could point El Torito to the appended partition, thus eliminating the need for the /boot/grub/efi.img file.) > From what I can see, the maximum individual file name length when using > Joliet extensions is 128 "characters" It's less. A Joliet directory record has the same maximum size as an ISO directory record: 255 bytes. Joliet encodes names in UCS-2 which uses 16 bit per character. The fixed header part of a directory record is 34 bytes large. So only 110 UCS-2 characters have room. For some reason libisofs offers to write 103 characters at most. (It's long ago that this decision was made not by me.) In file /mnt/iso/.disk/mkisofs i see the recorded -as mkisofs option: -joliet-long which means according to man xorrisofs: Allow 103 characters in Joliet file names rather than 64 as is prescribed by the specification. Allow Joliet paths longer than the prescribed limit of 240 characters. > if you are using Windows' native utilities, you won't be able > format a partition that is larger than 64 GB to FAT32, The largest official Debian ISOs are 50 GB. But i have a script which can merge a complete set to a ~90 GB ISO. :)) Have a nice day :) Thomas