Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

James Addison wrote:
> My interpretation of the commands and output in your comment is that both
> genisoimage and xorriso can translate hardlinks from a source filesystem
> into deduplicated file references in a written ISO filesystem

With genisoimage we only know empirically. With libisofs under xorriso
i can tell that a red-black-tree of device and inode numbers is used to
match hard links. This is well tested by Debian ISOs because already now
the Linux kernels are hard link siblings.
E.g. in firmware-bookworm-DI-alpha1-amd64-netinst.iso 15 MB are won:
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,    35982 ,     3761 ,  7700896 , '/install.amd/gtk/vmlinuz'
  File data lba:  0 ,    35982 ,     3761 ,  7700896 , '/install.amd/vmlinuz'
  File data lba:  0 ,    35982 ,     3761 ,  7700896 , '/install.amd/xen/vmlinuz'

If genisoimage would not deduplicate some hardlinks then the ISO would
simply become larger but stay functional for the boot paths which
debian-cd prepares and also for the file copying method which Pete Batard
wants to get enabled.


This method is intended for booting via EFI from USB stick. In general i
support Pete Batard's goal to have bootable ISOs ready for it, regardless
whether it is a wish or the fix of a regression.
(I looked into firmware-11.6.0-amd64-netinst.iso and found its /firmare
directory filled with symbolic links and one sub directory ./deb11.)

The file extraction method is supposed to be a behavioral pattern of
experienced users of MS-Windows. Let's be inviting to them or else they
might install Debian on WSL.


Have a nice day :)

Thomas