It should be possible to build a disc1 ISO image via (cd release && make -DNO_ROOT disc1.iso) The resulting image is bootable and is functional, but inspecting the contents via tar (which includes read-only ISO9660 support) shows most files missing and oddities like drwx------ 18 0 0 4096 Feb 13 13:53 . drwxr-xr-x 2 0 0 6144 Feb 13 13:53 bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/cat link to bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/chflags link to bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/chio link to bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/chmod link to bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/cp link to bin -r-xr-xr-x 6 0 0 0 Feb 13 13:53 bin/cpuset link to bin -r-xr-xr-x 2 0 0 455816 Feb 13 13:53 bin/csh -r-xr-xr-x 2 0 0 0 Feb 13 13:53 bin/tcsh link to bin/csh -r-xr-xr-x 5 0 0 20848 Feb 13 13:53 bin/date jrtc27 reports this is the case also for an arbitrary late-2023 CheriBSD ISO (so not a recent regression)
Note that when mounting the image, e.g. via mdconfig -a -f disc1.iso mount -t cd9660 /dev/md0 /mnt the contents look as I'd expect
The issue is that there are a number of Rock Ridge PX fields with "POSIX File Serial Number" equal to zero. From IEEE P1282 > "BP 37 to BP 44 - POSIX File Serial Number" shall have the same meaning as > and may be used for the st_ino field of POSIX:5.6.1. This field shall be > recorded according to ISO 9660:7.3.3. Directory Records which share the > value of this field are defined as links (see POSIX:2.2.2.17) and, by definition, > point to the same file or directory. > > Note: Use of the phrase "may be used for" in [4], [6], [7], and [8] is intended to > provide for the possibility of mapping these values when used by a receiving system > provided that, in the case of [8], the meaning of st_ino is preserved as a unique > identifier of the file. Kernel cd9660 ignores this field, which explains why it has no issue with the image: static int cd9660_rrip_attr(ISO_RRIP_ATTR *p, ISO_RRIP_ANALYZE *ana) { ana->inop->inode.iso_mode = isonum_733(p->mode); ana->inop->inode.iso_uid = isonum_733(p->uid); ana->inop->inode.iso_gid = isonum_733(p->gid); ana->inop->inode.iso_links = isonum_733(p->links); ana->fields &= ~ISO_SUSP_ATTR; return ISO_SUSP_ATTR; }
At the time of import NetBSD's makefs did not populate the PX serial (and still does not). We added it in: commit 516e01684419a7475cd3ce04d2777d56979e4a45 Author: Marius Strobl <marius@FreeBSD.org> Date: Sun Dec 29 16:43:35 2013 +0000 Record the IEEE P1282 Rock Ridge version 1.12 POSIX File Serial Number, i. e. the POSIX:5.6.1 st_ino field, which can be used to detect hard links in the file system. This is also the default in mkisofs(8) and according to its man page, no system only being able to cope with Rock Ridge version 1.10 is known to exist. PR: 185138 Submitted by: Kurt Lidl MFC after: 1 week
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=518cdd344ec51584478f39b9a9cac77fc0766ce1 commit 518cdd344ec51584478f39b9a9cac77fc0766ce1 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2025-02-26 16:44:12 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2025-02-28 20:34:52 +0000 makefs: Make cd9660 Rock Ridge inodes reproducible Rock Ridge extensions include an inode field: "POSIX File Serial Number" shall have the same meaning as and may be used for the st_ino field of POSIX:5.6.1. This field shall be recorded according to ISO 9660:7.3.3. Directory Records which share the value of this field are defined as links (see POSIX:2.2.2.17) and, by definition, point to the same file or directory. Previously we'd store the source file's st_ino (except that in metalog mode we'd record 0 for files with nlink = 1). This had two issues: the generated ISO image was nonreproducible due to the arbitrary inode numbers, and files without hard links would falsely be detected (by certain tools) as hard links to each other. Note that the kernel's cd9660(5) file system ignores the Rock Ridge PX File Serial Number, so this issue isn't observed by mounting such a file system. Instead of using the source inode directly, assign target inode numbers sequentially. Use a map so that files with the same source inode (hard links) still receive the same target inode number. PR: 284795 PR: 285027 Reviewed by: brooks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49141 usr.sbin/makefs/cd9660.h | 12 +++++++ usr.sbin/makefs/cd9660/iso9660_rrip.c | 67 ++++++++++++++++++++++++++++++----- usr.sbin/makefs/cd9660/iso9660_rrip.h | 2 +- 3 files changed, 71 insertions(+), 10 deletions(-)