Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support
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
Reply to: