Back in 2012 I created a 7.5GB file named


My guess is that I ran dd on an 8GB SD card from one of my cameras. Why? Can't remember.

I confirmed that ec6a4994f4148912abb199505b98f01g in its filename is its md5sum, so the file is intact relative to whenever I added its sum to its name.

file reports that is data.

partx reports 'failed to read partition table'. never used partx before.

fdisk reports 'doesn't contain a valid partition table'

sudo losetup -f <filename> puts it at /dev/loop0 as reported by losetup -a, but doesn't make any loop0pN, and my subsequent attempts at mount -t <type> /dev/loop0 <mount-point> fail as above.

mount -o loop -t auto fails, saying I need to specify the filesystem type. It also fails if I specify vfat or ntfs.

Seeking advice on how to proceed.

  • partx and fdisk report no partition table – Jeff Sep 27 '16 at 0:55
  • photorec the loop device? or hexdump -C | less, binwalk, ... – frostschutz Sep 27 '16 at 1:06
  • thanks for hexdump -C; I see a camera model (which is one of mine) and sensible dates and times. I don't have photorec in any repositories, but I'll look into that if it comes down to that. – Jeff Sep 27 '16 at 1:26

Make a loop device yourself and inspect what's in it from there. This can be accomplished with the following (with commands updated to reflect your environment, if these do not):

Find an unused loop device:

losetup -f

Create a loop device with that SD card file:

losetup /dev/loop0 /path/to/SD-card.2012.dd bs1024-1.ec6a4994f4148912abb199505b98f01g

Since it's an SD card, it probably doesn't have a partition table, and likely has just a filesystem sitting directly on it. You can now address /dev/loop0 as a block special, and see about what kind of filesystem might be on it.

Display filesystems as scannable by your system:


When you know what the filesystem / partition structure is, try to mount it. YMMV, as you might have something odd on that SD card (such as LVM). But it's probably a filesystem directly on it:

mount /dev/loop0 /mnt/foo
  • after losetup -f <filename> and losetup -a; blkid -p /dev/loop0 does not report anything at all. I'm not sure what you mean by can now address /dev/loop0 as a block special – Jeff Sep 27 '16 at 1:17
  • I mean that you can access your file as a block device directly now that it's being addressed by loop0. If blkid doesn't spit out something immediately, you;re going to have to probe around it a bit. fdisk or parted could be useful in this case, at least to see if there is a partition structure on it. You could also try mounting it to see if we can automatically determine the contents of /dev/loop0. Finally, the file command can be very useful here, with the -s switch to read special devices. Such as: file -sL /dev/loop0 – Spooler Sep 27 '16 at 1:38
  • fdisk /dev/loop0 reports 'Device contains neither a valid DOS partition table, nor ...' – Jeff Sep 27 '16 at 1:49
  • file -sL /dev/loop0 reports it to be 'sticky data'. Time for me to find out what that means – Jeff Sep 27 '16 at 1:50
  • I'm interested to know what that means, too. I don't see much on it aside from bewildered people with inaccessible disks that are using file to determine their contents before mounting. Are you sure this has valid data, or do you have any idea what it might have on it? Or do you know what filesystem it could have? I'd guess FAT, if it came from a camera. Some details like that would help at this point, as we could use something like testdisk to scan the thing for lost or damaged partition tables and / or filesystems. – Spooler Sep 27 '16 at 1:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.