How to mount backup.img.raw(an ext4 image file) on the host at a mount point of your choice


Can you show me How to mount backup.img.raw(an ext4 image file) on the host at a mount point of your choice?

thank you.

This will be the same as most mount operations, but it will require using the loopback option. As an alternative, you could cover the file with loopback, and then mount the loopback device (which would not require a loopback option).

Typical example using loopback option:
sudo mount -o loop backup.img.raw /mnt
…then umount:
sudo umount /mnt

There are a lot of different ways to do the same thing with losetup, be sure to check man losetup.

This is equivalent of finding and creating the first unused loop device, and attaching this to the file, followed by mounting the device. It is important to know that any user can find the first unused loop device, but only root (or sudo) can actually create that device. This will find, but not create the name of the next unused loop device:
losetup --find
…this will not only find the device, it will also create the device:
sudo losetup --find

Note that “-f” is synonymous with “--find”. In operations which bind a loopback device with a file you can also include “-f” to tell you which loopback device bound to the file. Example:
sudo losetup -f backup.img.raw

To see which device is attached to the file:
sudo losetup -j backup.img.raw

If that file is associated with “/dev/loop0”, then this would mount:
sudo mount /dev/loop0 /mnt
(notice that I did not say “-o loop”)

Any of these would umount:
sudo umount /mnt
sudo umount /dev/loop0

If a file is not mounted, and is covered by loopback, but you want to detach the loop device (you only have so many loop devices, it is a bad idea to keep creating them and not releasing them…it is similar to a memory leak):
sudo losetup -d /dev/loop0

Or to just detach everything loop which can be detached (meaning not in use):
sudo losetup -D

If you are experimenting, and want your loopback device to be read-only:
sudo mount -o loop,ro backup.img.raw

If you want to see the status of all loop devices:
losetup -a

1 Like

If I try, I will respond.
Thank you very much for the kind explanation.

once the image is mounted it might be possible to chroot into it from the Host PC

1 Like

This is correct, but since the PC is a different architecture, one would have to do that with QEMU.

If you were to chroot in an image which is also the same architecture as the PC, then you would basically do this:

sudo -s
cd /where/ever/the/image/is
mount /sys ./sys -o bind
mount /proc ./proc -o bind
mount /dev ./dev -o bind
chroot .
# stuff...
# Exit the chroot.
# Exit the sudo -s.

I don’t know all of the details for QEMU, but you’d basically do the same thing with QEMU in the mix if this is cross architecture. I forget where it is, but @mdegans has a nice script related to this. If @mdegans sees this, maybe he could link his git URL for the script.

yes, it might be more handy to do chroot from AGX, that has the same processor architecture set;
quemu setup might be complicated for Host PC x86_64

1 Like

Sorry for the delay. Been occupied with contract work recently. Here is a link to the script i beleive you’re thinking of.

On x86-64 Debian/Ubuntu you must sudo apt install qemu-user-static first. On aarch64 it will probably work as is, I haven’t tested.

Here’s a thread with some instructions on how a rootfs folder can be edited using the script:

I haven’t tested it with a mounted img, but provided you get it actually mounted rw, it should work fine.

1 Like

That’s the one! Thanks! This is a really good way to find out how chroot works in combination with QEMU (the QEMU parts work to hint to the Linux host PC o/s how to use QEMU as a kind of architecture adapter to run commands like “apt” or user name/pass creation using tools instead of using direct edits). A loopback mounted image can be used in place of the “Linux_for_Tegra/rootfs/” content.

1 Like