The Slackware64 file tree contains two identical copies of initrd.img. It also has two identical kernels, albeit with different names:

This means every time I update my local mirror and there's been a kernel/initrd update, I have to download 56 megabytes of duplicate data.

Can we eliminate the EFI copy of initrd.img and huge.s from the file tree and, in its place, modify the xorriso call in isolinux/README.TXT to use graft points? Like so:

Edit: It would be good to add a README.TXT to EFI/BOOT to explain that it will be populated with initrd.img and bzImage when the image is created with the command line found in isolinux/README.TXT.

There's also usb-and-pxe-installers/usbboot.img, but it is distinct and needs to stay that way. initrd.img and bzImage, however, are low-hanging fruit when it comes to reducing bandwidth and disk storage needs for mirrors.

As an added bonus, at least with xorriso (not sure about true-blue mkisofs), this reduces the resultant disc image by 57.2 megabytes (I measured, will obviously change along with initrd.img and huge.s). I assume the grafted filenames get mapped to the same LBA. I can dive into the ISO9660 structures to confirm if need be, but I think it's self-evident. Anyway, this will be a savings for people who download, mirror, or burn the ISO images, even if they don't care about the file tree. I imagine this will encompass the majority of Slackware end users.

Mounting the disc images created with and without -graft-points and then diff'ing their file trees shows no differences. The only difference I can spot is by listing directories with "ls -li": Even though the initrd.img and kernel files have distinct inodes, they have link counts of 2 rather than 1.

At long last, I have the answer to the ancient riddle: When is a hard link not a hard link?

I've been creating and booting custom installer images created in this manner for several months now (since January) and have had no issues. I did so because I've been making and using custom initrd.img files to add vmd and custom packages and scripts I wanted/needed during installation, before the first live boot, and I found graft points to be easier and safer than commingling my custom stuff throughout the mirrored tree, which would have necessitated carefully crafting my rsync command line to protect my files.

Actually I should qualify that statement. I didn't spot the opportunity to merge kernel files until this morning, but initrd merging I've been doing all year long. To make sure it's still good, I successfully booted a fresh image created with the above command line.

Edit 2: I booted using VirtualBox using both BIOS and EFI modes. Both worked.

This discussion applies only to 64-bit Slackware since the EFI directory doesn't appear on 32-bit Slackware.

Not, if you add -H to your rsync command:
(Edit: it may depend on the rsync host if the hard links are there.)

Which they are on slackware.uk

Hi,

> The only difference I can spot is by listing directories with "ls -li":
> Even though the initrd.img and kernel files have distinct inodes, they
> have link counts of 2 rather than 1.

Files with identical inode on the input hard disk get their content mapped
to the same data range in the ISO. So this is much like a hard link.

With xorriso setting -compliance "new_rr" they even get the same Rock Ridge
"serial number". But the inode number in Linux is not derived from that
info. Instead the byte position of the directory record is used, divided
by 32.
(An ISO 9660 directory record holds name and pointer to data content.
So it is like a combination of dirent and inode. Such a record has at
least 34 bytes. So dividing by 32 still yields unique numbers.)

Funnily, Linux shows the number from the Rock Ridge link count field.
(Both, count and serial number, are in Rock Ridge PX entries.)

Have a nice day

Thomas

1 members found this post helpful.

Yes, you are right. A Slackware tree mirrored using rsync -aH, EFI/BOOT/huge.s and kernels/huge.s/bzImage point to the same inode (with a link count of 2). Then the xorriso command line in slackware64-current/isolinux/README.TXT makes slackware-dvd.iso where those two names huge.s and bzImage point to the same zone.

But for some reason, in the original slackware64-14.2-install-dvd.iso, they point to different zones. A rebuild with the mkisofs command in slackware64-14.2/isolinux/README.TXT makes them use the same zone. Maybe P.V. built the iso using a slackware tree copied without hard links.

Hi,

> [...] in the original slackware64-14.2-install-dvd.iso, they point to
> different zones. [...] Maybe P.V. built the iso using a slackware tree
> copied without hard links.

Seems so.

Since its beginnings, libisofs underneath xorriso unites data files
which have the same pair of (dev_t, ino_t) numbers on the input disks.
There never was a way to disable this feature and afaik it was never broken.

I have an occasion where libisofs has no chance to make the connection
between files, though:
My regression tests build test ISOs from mounted original ISOs. Due to the
inode computation of Linux, each input file shows a different inode number
and thus occupies its own space in the data storage of the new ISO.
(The new ISO lives just long enough to compare its boot records and data
file content with those of the original ISO.)

---------------------------------------------------------------------------

I had a look at:
https://mirrors.slackware.com/slackw...nstall-dvd.iso

I see traces of old bugs in the ISOLINUX postprocessing program isohybrid,
option --uefi.
(Wrong GPT backup block address, pseudo-chinese GPT partition names.)

The sequence of Rock Ridge entries looks like from mkisofs or genisoimage.
(mkisofs writes RR and NM before PX. libisofs writes PX first.)

Have a nice day

Thomas

1 members found this post helpful.