Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support
Followup-For: Bug #1031696
On Sat, 11 Mar 2023 18:10:22 +0100, Thomas Schmitt wrote:
> ifneq (,$(filter i386 amd64 arm64 hppa,$(ARCHES)))
> Surely i386, amd64, and arm64 get their published Debian ISOs made
> by xorriso.
I think your expectation is correct there, yes: looking further into the
commit history, xorriso became the default[1] for i386/amd64 a while ago, in
March 2013.
> So let's test hardlink handling in genisoimage:
>
> $ ls -l /u/test/hardlinks
> total 88
> -rw-r--r-- 2 thomas thomas 42786 Nov 14 2005 hardlink_x
> -rw-r--r-- 2 thomas thomas 42786 Nov 14 2005 x
> $ genisoimage -o test2.iso -R /u/test/hardlinks
> ...
> 196 extents written (0 MB)
>
> We inspect the resulting ISO by xorriso:
>
> $ xorriso -indev test2.iso -find / -type f -exec report_lba --
> ...
> Report layout: xt , Startlba , Blocks , Filesize , ISO image path
> File data lba: 0 , 25 , 21 , 42786 , '/hardlink_x'
> File data lba: 0 , 25 , 21 , 42786 , '/x'
> $
>
> Both files in the ISO refer to the same block range starting at 2048-byte
> block 25 up to block 45. So in the ISO, they are deduplicated
>
> Now for a bit of kernel slapstick:
>
> $ sudo mount test2.iso /mnt/iso
> mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
> $ ls -li /mnt/iso
> 1479 -rw-r--r-- 2 thomas thomas 42786 Nov 14 2005 hardlink_x
> 1483 -rw-r--r-- 2 thomas thomas 42786 Nov 14 2005 x
>
> Note the link count 2 in combination with the differing inode numbers.
> (The link count stems from Rock Ridge field PX. By mistake i mentoned it
> as "PN" in my previous mail.)
>
> The false link count does not hamper restoring of the files:
>
> $ cp -r /mnt/iso /u/test/hardlinks_restored
> $ ls -li /u/test/hardlinks_restored
> total 88
> 8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 hardlink_x
> 8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 x
>
> So the files are independent after being restored by Debian 11 to ext4.
>
> The same happens with an ISO made by xorriso:
>
> $ xorriso -as mkisofs -o test.iso -R /u/test/hardlinks
> ...
> $ xorriso -indev test.iso -find / -type f -exec report_lba
> ...
> Report layout: xt , Startlba , Blocks , Filesize , ISO image path
> File data lba: 0 , 33 , 21 , 42786 , '/hardlink_x'
> File data lba: 0 , 33 , 21 , 42786 , '/x'
>
> $ sudo mount test.iso /mnt/iso
> ...
> $ cp -r /mnt/iso /u/test/hardlinks_restored
> $ ls -li /u/test/hardlinks_restored
> total 88
> 8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
> 8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 x
>
> Just to prove that the restored files are really not hardlinked:
>
> $ echo some_tail_bytes >> /u/test/hardlinks_restored/x
> $ ls -li /u/test/hardlinks_restored
> total 88
> 8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
> 8913419 -rw-r--r-- 1 thomas thomas 42802 Mar 11 17:48 x
> $
Thank you very much for doing this and sharing the results.
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, and that simple
copying of those files from the filesystem when mounted creates unlinked,
separate copies of them, as would be suitable to create a UEFI boot drive using
only a standard file explorer (as included in most-or-perhaps-all operating
systems and without requiring the user to provide custom options when
performing the copy).
If that's correct then I might have some follow-up suggestions, but I'd like to
get a general sense of agreement from folks on the details before that.
[1] - https://salsa.debian.org/images-team/debian-cd/-/commit/b77a268aa291ea3cdb3811da474b67fd7073c2cf
Reply to: