Hi,
Richard Owlett wrote:
> I don't grok loop devices. [...]
> Also the article I read evidently took advantage of "mount" being able to
> loop mount without the loop option being explicitly referenced.
Yes. mount is smart enough to see that your "device" is a data file and
that it has to use a loop device.
A little test as superuser with already existing directory /mnt/iso:
# mount debian-10.6.0-amd64-netinst.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only
# ls /mnt/iso
EFI
...
win32-loader.ini
So it used the existing /dev/loop0. If no idle loop device is available
then it will create a new one.
See in man mount the section
THE LOOP DEVICE
> I wish to have the ISO's of all install DVDs on a dedicated
> partition of my hard drive as a local repository.
You could mount them all, e.g. by a script which knows all their names
and the desired mount points. Each mount point would need its own line
in sources.list.
-------------------------------------------------------------------------
Alternative:
Or you could also copy the ./pool trees of the one-by-one mounted ISOs to
a ./pool directory in the filesystem of your dedicated partition.
I understand that sources.list will then want the directory above ./pool
as source for packages. I.e. if you copy to
/your/partition/pool
then it wants to see in the deb line
/your/partition
Possibly you will have to set in that line the option
[trusted=yes]
to compensate the lack of a skilled Debian setup in your copied tree.
-------------------------------------------------------------------------
Alternative:
For copying without being superuser and without mounting the ISO, you could
use xorriso. Like:
ISO_PATH=./debian-10.6.0-amd64-netinst.iso
xorriso -osirrox on:auto_chmod_on \
-indev "$ISO_PATH" \
-extract /pool /your/partition/pool
The option "auto_chmod_on" of xorriso command -osirrox causes:
[that] access restrictions for disk directories get circumvented if
those directories are owned by the effective user who runs
xorriso. This happens by temporarily granting rwx permission to
the owner.
The first ISO extraction will work without this option. But when copying
multiple trees from ISOs to disk, it will enable xorriso to write into the
previously created directories under /your/partition/pool and to overwrite
existing files in that tree. Both is elsewise hampered by the fact that
xorriso copies the access permissions from the ISOs, where they are set to
be read-only.
-------------------------------------------------------------------------
Alternative:
Another method would be to let xorriso change the permissions in the ISO
before extraction and to tell it to discard the permission changes rather
than trying to write them as new session:
xorriso -osirrox on \
-indev "$ISO_PATH" \
-chmod_r u+rw /pool -- \
-extract /pool /your/partition/pool \
-rollback_end
The "--" after -chmod_r is important because it ends the list of paths
to manipulate.
The command -rollback_end prevents the attempt to write a new session after
you made changes to the loaded ISO. Without it (and without an -outdev)
you would get an error message after successfule extraction:
xorriso : FAILURE : No output drive acquired on attempt to write
and the exit value would be non-zero.
The extracted files will not be read-only afterwards. This eases manipulation
and removal of the pool tree, but also gives no protection against removal
by mistake. Read-only trees will need superuser power or a run of chmod -R
before you can remove files or the whole tree.
Have a nice day :)
Thomas
