Trying to pull data off a possibly corrupt SD card.
I’ve mounted it on Freepbx and can see the file system is apparently GPT
but when I got to mount it, the directory is empty
sometimes seems to contain a single non-file called ‘image’
thanks
FreePBX doesn’t care. Do you mean the SNG distribution of Linux?
GPT, in any case, relates to partition tables, not filesystems.
I wonder if you are trying to mount the partition table (/dev/sdX), rather than the actual data partition (/dev/sdX1, etc.).
What do you get if you enter “cat /proc/partitions” at a Linux shell prompt, and which /dev node were you trying to mount?
Sorry, yes, I mean CentOS
When I first connect the SD card I get this
which never returns back to a command prompt, then
blkid should identify the filesystem on each of those 8 partitions
getting a lot of SQUASHFS error: filesystem uses “unknown” compression…
The squashfs partitions aren’t going to contain any user data. They are also read only, so they shouldn’t contain anything which isn’t available elsewhere.
hmmm, every non squash partition I attempt to mount is empty. No errors generated just nothing showing when I ‘ls’.
Very strange as the SD card does boot properly when inserted into a Pi, it just falls over not long after that
Is what df shows consistent with their really being empty?
For the ext* systems, preferably with them not mounted, see if “e2fsck -n -f” indicates any damage or lost files. The -n is important, as it stops it trying to repair any damage it finds, which might lose more data if the filesystem is already corrupt.
This is an example of what you will get for a, fairly full filesystem, in good condition:
root@dhcppc4:~# e2fsck -n -f /dev/sda10
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Debian_Root: 445936/1954064 files (0.4% non-contiguous), 7323854/7812608 blocks
and this is the result for a rather small one, immediately after creation, so as empty as it ever should be:
david@dhcppc4:~/Downloads$ /sbin/e2fsck -n -f /tmp/extfs
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/tmp/extfs: 11/25688 files (0.0% non-contiguous), 4800/102400 blocks
1 Like
Thank you for your time and energy here, really appreciate it
Eventually I rebooted the Pi (again) and it seemed to do some kind of repair sequence and is now functioning normally again. For now.
I’m still super confused what it was doing to the network to take devices offline but hey ho.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.