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