Hoping I can recover my SD card

phunni · 2017-03-10 14:25:49

I recently managed to destroy an SD card that was in my Android tablet - I think it was when a system upgrade hung and I had to restart the device.

So, I dutifully switched the card into my Arch laptop to try and see if I could fix it. Running "fsck -v /dev/sdb" returns:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/sdb contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 251131903 sectors, extended partition table (last)' data

When I saw the DOS/MBR bit at the bottom I decided to try and run "fsck.vfat -v /dev/sdb" :

fsck.vfat -v /dev/sdb
fsck.fat 4.0 (2016-05-06)
Logical sector size is zero.

Running testdisk doesn't seem to reveal any problems - it claims that the partitions are all intact and OK. For some reason, though, the system seems to think that the card is empty and, if I try it in my tablet again, it simply acts as if it isn't there.

I have tried simply mounting it in Arch and, not surprisingly, it fails. dmesg reveals the error when mounting:

[65379.425561] FAT-fs (sdb1): bogus number of reserved sectors
[65379.425570] FAT-fs (sdb1): Can't find a valid FAT filesystem

Trilby · 2017-03-10 14:48:30

First, your fsck output is all nonsense. You are trying to run a file system check on a device. filesystem checks are only applicable to filesystems - which usually reside on partitions, not devices. `lsblk -f` would be a good starting point so we have at least a vague idea what we are working with.

phunni · 2017-03-10 14:54:24

Fair enough - here's the output of "lsblk -f /dev/sdb":

NAME   FSTYPE LABEL UUID MOUNTPOINT
sdb                      
├─sdb1                   
└─sdb2

That doesn't seem like it would be all that helpful, so here's the output of "fdisk -l /dev/sdb":

Disk /dev/sdb: 119.8 GiB, 128579534848 bytes, 251131904 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3C50836A-D231-41AF-BBB6-285132EDB705

Device     Start       End   Sectors   Size Type
/dev/sdb1   2048     34815     32768    16M unknown
/dev/sdb2  34816 251131870 251097055 119.7G unknown

cfdisk reveals that the partitions are named "android_meta" and "android_expand" respectively. It is also unable to determine the type.

Incidentally, I've discovered since posting the original post that storage media used as adopted storage in Android (as this card was) cannot be mounted elsewhere. This may account for some of the above listed errors. Nevertheless, something is broken on the card and I'm still hoping I can fix it...

Trilby · 2017-03-10 15:21:31

It seems android devices use a wide range of filesystems that would not be mountable/readable/fsckable by most linux systems without specifically installing support for that filesystem (e.g. YAFFS, for which there seem to be some packages in the AUR). Other android devices can even use proprietary filesystems which you'd never be able to access by plugging the sd card into your computer.

Your best bet would be to leave the card in the android device, and use something like adb to connect to it to explore the filesystem(s).

phunni · 2017-03-10 15:23:05

Thanks for the reply. Unfortunately, the Android device simply isn't recognising that there's even an sd card in there...

mich41 · 2017-03-10 17:06:06

Maybe file would identify it?

file -s /dev/sdb*

phunni · 2017-03-10 18:28:00

result of "file -s /dev/sdb*":

/dev/sdb:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 251131903 sectors, extended partition table (last)
/dev/sdb1: data
/dev/sdb2: data

mich41 · 2017-03-10 22:52:45

So it didn't.

Probably it's what Trilby said: they use some uncommon filesystem. Maybe try this list. I have no idea how complete it is, BTW.

The chance of this happening on both partitions is slim, but there is also possibility of superblock corruption. Try ext4/fat32 fsck on these two partitions if you haven't already.

And ultimately, do you want to recover the card itself or data? If only the former, just repartition and reformat it.

Trilby · 2017-03-10 23:00:07

mich41 wrote:

Try ext4/fat32 fsck on these two partitions if you haven't already.

That doesn't make any sense if they are not ext4 or fat32 which they are not.

mich41 · 2017-03-10 23:09:39

There is a chance of corrupted superblock misleading file. IIRC, OP only ran fsck on the whole disk, not partitions, so it's not clear what they are or aren't. For the record, I don't expect miracles, but a quick fsck is much less work then downloading tools for exotic filesystems so I'd give it a try.

Trilby · 2017-03-10 23:13:30

mich41 wrote:

There is a chance of corrupted superblock misleading file.

That's irrelevant. `file` will not tell you the filesystem even if it is a perfectly in tact common filesystem. See post #3, these are neither ext{2,3,4} or vfat nor any other filesystem known to the running kernel.

mich41 · 2017-03-11 09:07:34

Trilby wrote:

That's irrelevant. `file` will not tell you the filesystem even if it is a perfectly in tact common filesystem.

It will.

Trilby wrote:

See post #3, these are neither ext{2,3,4} or vfat nor any other filesystem known to the running kernel.

Post #3 only shows that two userspace utilities can't identify it. Dunno about cfdisk, but lsblk takes data from udev. And I wouldn't be surprised if udev used file internally Or its own reimplementation of file, it's a systemd project after all. In any case, I don't think the kernel probes disks for filesystems before you request mounting. Partition tables sure, but not filesystems AFAIK.

Trilby · 2017-03-11 11:21:43

No. File really will not give any information about filesystems. File looks for input *from* the parent filesystem, magic numbers, or the language of text files. Unlike you I tested this before commenting and am not making up nonsense:

$ file /dev/sd*
/dev/sda:  block special (8/0)
/dev/sda1: block special (8/1)
/dev/sda2: block special (8/2)
/dev/sda3: block special (8/3)
/dev/sdb:  block special (8/16)
/dev/sdb1: block special (8/17)

And your veiled slander of systemd also contributes nothing to this thread and is also simply wrong.

R00KIE · 2017-03-11 13:50:23

What you haven't told us so far (unless I've missed it) is how you were using the sd card with your android device. Have you formatted or have you been asked to format the card when you put it in your android device? Was it being used as internal/adopted storage or just "normal" storage?

Do you have another card you can use the same way? That would allow you to get a "good" card out of the device and check which filesystem is being used. The alternative would be to make an image of your "bad" card and put it your android device again and then check which filesystem is being used.

Scimmia · 2017-03-11 14:02:47

R00KIE wrote:

What you haven't told us so far (unless I've missed it) is how you were using the sd card with your android device. Have you formatted or have you been asked to format the card when you put it in your android device? Was it being used as internal/adopted storage or just "normal" storage?

phunni wrote:

Incidentally, I've discovered since posting the original post that storage media used as adopted storage in Android (as this card was) cannot be mounted elsewhere. This may account for some of the above listed errors. Nevertheless, something is broken on the card and I'm still hoping I can fix it...

R00KIE · 2017-03-11 16:28:44

Figures I'd miss it

This might be worth exploring though https://nelenkov.blogspot.pt/2015/06/de … orage.html

If you manage to decrypt the volume then running fsck on the filesystem might help, but I'd do a full image of the card before starting to run fsck or anything else, just in case you make it worse instead of better.

seth · 2017-03-11 17:27:55

phunni wrote:

Running testdisk doesn't seem to reveal any problems - it claims that the partitions are all intact and OK. For some reason, though, the system seems to think that the card is empty and, if I try it in my tablet again, it simply acts as if it isn't there.

How exactly did you run testdsik?
What's the output of "testdisk /list /dev/sdb"?

mich41 · 2017-03-11 17:43:14

Trilby wrote:

Unlike you I tested this before commenting and am not making up nonsense

That's funny because I did too

# file -s /dev/sda*
/dev/sda:  DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000, stage2 segment 0x200
/dev/sda1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
/dev/sda2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)

Trilby · 2017-03-11 20:02:01

I stand corrected, with the '-s' flag file can do that. Sorry mich.

*eats his parrot's hat*

phunni · 2017-03-11 21:07:33

file -s /dev/sdb*
/dev/sdb:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 251131903 sectors, extended partition table (last)
/dev/sdb1: data
/dev/sdb2: data

At this stage I've given up hope on trying to rescue the data ont he card and would be happy just ot be able to reformat it. Trouble is, any attempt to wipe the existing partitions simply fails without error. fdisk lists the partitions as:

Disk /dev/sdb: 119.8 GiB, 128579534848 bytes, 251131904 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3C50836A-D231-41AF-BBB6-285132EDB705

Device     Start       End   Sectors   Size Type
/dev/sdb1   2048     34815     32768    16M unknown
/dev/sdb2  34816 251131870 251097055 119.7G unknown

If I try an delete them and rewrite the partition table it says I've succeeded, but nothing has actually changed. I don't have write lock on the disk ;-p

mich41 · 2017-03-11 22:29:11

Maybe

wipefs -a /dev/sdb?
wipefs -a /dev/sdb
dd if=/dev/zero of=/dev/sdb count=1

If these things execute without errors and it still shows partitions after reinserting the card, the card is probably broken.

seth · 2017-03-11 22:32:41

software readonly?

hdparm -r /dev/sdb

Also check dmesg for errors ("dmesg -w" for a "live" version)

ween_trigger · 2019-04-19 15:23:10

Sorry to necropost, but did anyone ever figure this out? I have precisely the same problem, with no success on wiping the card yet.

V1del · 2019-04-19 15:27:55

Please don't do that, chances that you have the exact same situation are relatively small, create your own thread noting your own troubleshooting steps and actions you've taken in an attempt to do this, as well as the diagnostic commands mentioned here.

Closing.

Arch Linux

#1 2017-03-10 14:25:49

Hoping I can recover my SD card

#2 2017-03-10 14:48:30

Re: Hoping I can recover my SD card

#3 2017-03-10 14:54:24

Re: Hoping I can recover my SD card

#4 2017-03-10 15:21:31

Re: Hoping I can recover my SD card

#5 2017-03-10 15:23:05

Re: Hoping I can recover my SD card

#6 2017-03-10 17:06:06

Re: Hoping I can recover my SD card

#7 2017-03-10 18:28:00

Re: Hoping I can recover my SD card

#8 2017-03-10 22:52:45

Re: Hoping I can recover my SD card

#9 2017-03-10 23:00:07

Re: Hoping I can recover my SD card

#10 2017-03-10 23:09:39

Re: Hoping I can recover my SD card

#11 2017-03-10 23:13:30

Re: Hoping I can recover my SD card

#12 2017-03-11 09:07:34

Re: Hoping I can recover my SD card

#13 2017-03-11 11:21:43

Re: Hoping I can recover my SD card

#14 2017-03-11 13:50:23

Re: Hoping I can recover my SD card

#15 2017-03-11 14:02:47

Re: Hoping I can recover my SD card

#16 2017-03-11 16:28:44

Re: Hoping I can recover my SD card

#17 2017-03-11 17:27:55

Re: Hoping I can recover my SD card

#18 2017-03-11 17:43:14

Re: Hoping I can recover my SD card

#19 2017-03-11 20:02:01

Re: Hoping I can recover my SD card

#20 2017-03-11 21:07:33

Re: Hoping I can recover my SD card

#21 2017-03-11 22:29:11

Re: Hoping I can recover my SD card

#22 2017-03-11 22:32:41

Re: Hoping I can recover my SD card

#23 2019-04-19 15:23:10

Re: Hoping I can recover my SD card

#24 2019-04-19 15:27:55

Re: Hoping I can recover my SD card

Board footer