[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mounting live ISO images, inodes and NFS



Hi,

Andreas B. Mundt wrote:
> I guess, for a more advanced di-netboot-assistant,
> the relevant files need to be copied to the local file system, when
> sharing them via NFS is needed. If anybody knows a more elegant
> solution let me know!

Elegant i would not say, but if your problem is indeed in the equal inode
numbers then you could manipulate the byte address which is base of the
number computation of Linux.
Try adding a new session which will have a new directory tree:

  $ cp debian-live-12.0.0-amd64-standard.iso test.iso
  $ xorriso -dev test.iso -boot_image any keep -changes_pending yes
  ...
  ISO image produced: 920 sectors
  Written to medium : 1088 sectors at LBA 819200
  Writing to 'test.iso' completed successfully.

  $ sudo mount test.iso /mnt/iso
  mount: /dev/loop0 is write-protected, mounting read-only
  $ ls -i /mnt/iso/live/filesystem.squashfs
  52434890 /mnt/iso/live/filesystem.squashfs
  $ expr 52434890 '*' 32
  1677916480
  $

The superblock of test.iso was updated to point to the new directory
tree. It is supposed to be identical to the original one but sits at the
end of the original ISO. So the byte address divided by 32 yields a high
inode number.
(One has to add command -changes_pending "yes" in order to force writing
of such an elsewise rarely useful session.)

If the manipulated ISO does not make its filesystem.squashfs
distinguishable from the others, then you problem is likely not caused by
the number equalities.

If the manipulation helps indeed and if you are lucky then all desired
ISOs differ enough in size to yield disjoint inode number intervals by
disjoint byte address intervals of the newly appended directory trees.
If two ISOs are too near in size, we would have to ponder over adding
a pad-up session before adding the default-mount session.
The interval width depends on the number of files in the ISO. With
debian-live-12.0.0-amd64-standard.iso it is less than 920 * 2048 bytes.


Have a nice day :)

Thomas


Reply to: