See if this makes any sense to you...
This is a bit lengthy but I included lots of detail for anyone that might need it. I also did this for the first time today.
The short version:
I didn't find a /dev/loop0 automatically showing up on my linux laptop.
I ran binwalk against /dev/sda and got the info to run:
sudo losetup -o <offset> -f /dev/sda
and then mount /dev/loop0 or whatever loop dev number it is.
"<offset>" is to be replaced with the number in the output of binwalk.
The long version:
I'm not familiar with the usg 3p device.
Looking at the device page: https://openwrt.org/toh/ubiquiti/unifi_security_gateway_3p
I searched the OpenWrt Bootlog for "overlay" and "loop0" and found:
[ 11.670904] random: jshn: uninitialized urandom read (4 bytes read)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 14.327924] F2FS-fs (loop0): Mounted with checkpoint version = 8f5dc93
[ 14.336933] mount_root: switching to f2fs overlay
[ 14.344884] overlayfs: "xino" feature enabled using 32 upper inode bits.
[ 14.398807] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 14.420869] urandom-seed: Seeding with /etc/urandom.seed
[ 14.567751] procd: - early -
[ 14.570974] procd: - watchdog -
Which looks to be from OpenWrt SNAPSHOT, r20176-a63aeaecf1.
I don't know what might be different now.
I don't know if "overlayfs: "xino" feature enabled using 32 upper inode bits." will complicate mounting on your linux laptop.
Reinforced by the filesystem types available in https://downloads.openwrt.org/releases/24.10.0/targets/octeon/generic/ , it looks like it might use the pretty standard setup with the kernel on one partition and the root filesystem of type squashfs on a second partition and the writable overlay filesystem mounted as a loop device using the second partition but an offset to skip the immutable squashfs for "rootfs_data".
It helps to know specifics from when it is in use on the usg. Hopefully showing the info from the running system will be good enough.
I'll use the info from my "FriendlyElec NanoPi R4S" and you can adapt as needed for your usg.
We'll look at the info for "kernel", "root", and overlay on the usg so we know what to expect on the linux laptop.
On running OpenWrt system:
block info
/dev/loop0: UUID="990fdb02-1784-41f2-9e93-6309aa4043d1" LABEL="rootfs_data" VERSION="1.0" MOUNT="/overlay" TYPE="ext4"
/dev/mmcblk1p1: UUID="84173db5-fa99-e35a-95c6-28613cc79ea9" LABEL="kernel" VERSION="1.0" TYPE="ext4"
/dev/mmcblk1p2: UUID="e3c74bfd-081c4550-52536fdd-7a3f08e3" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
Note that /overlay is on /dev/loop0 and there is only one loop device.
Also note the TYPE="ext4". If your system uses jffs2, f2fs or something else a little more exotic than ext4, your linux laptop will need the drivers for that filesystem in order to mount it and give you access.
EDIT: I see in your follow-up post that your usg used f2fs for the overlay filesystem. You may need to install f2fs-tools on your linux pc and maybe a driver or two to mount and work with that if not yet installed.
If you had captured the offset when the usg was running from the usb stick that you now want to read from, it would eliminate having to have software with a lot of dependencies installed on your linux laptop.
On running OpenWrt system:
losetup -l
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 12058624 1 0 /mmcblk1p2 0 512
Without that info, you might be able to get the offset and filesystem info on your linux laptop with the following:
Plug the usb stick in to the linux laptop and determine what device it is.
On linux laptop:
lsblk or use something like Gnome Disks.
In my example it is /dev/sda.
Install if needed (lots of dependencies) and run:
sudo binwalk /dev/sda2
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 10884307 bytes, 2079 inodes, blocksize: 262144 bytes, created: 2024-09-23 12:34:46
10944512 0xA70000 Linux EXT filesystem, blocks count: 95808, image size: 98107392, rev 1.0, ext4 filesystem data, UUID=15c16104-614c-11e2-9e4e-859fd7b2d7b2, volume name "rootfs_data"
We see that the squashfs filesystem for /rom is at offset 0.
The filesystem for "rootfs_data" is at offset 10944512.
I think that offset will differ with each build.
Attach the data blocks to a loop device with a command like:
sudo losetup -o 10944512 -f /dev/sda2
(use the offset number for your setup on that specific usb stick.)
Check it with
sudo losetup -l .
There are other options you may want like --size-limit, --sector-size and --read-only .
Once the loop device is in place, mount the filesystem with Gnome Disks or the mount command etc.
Set as read-only if you want to be safe to not mess up files. Enable write access if you want to write files to it.
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 ext4 1.0 rootfs_data 15c16104-614c-11e2-9e4e-859fd7b29602 70.5M 6% /media/spence/rootfs_data
sda
├─sda1 ext4 1.0 kernel 84173db5-fa99-e35a-95c6-28613cc79ea9 11.4M 25% /media/spence/kernel
Read your files! :-)
I mounted the kernel and root filesystems as a test and to learn. I spent a lot of time looking for a place where the offset might be stored where OpenWrt might get the info at boot time and to avoid needing binwalk to mount it on a linux pc.
