You are not logged in.
My Android phone stopped recognizing my expanded storage SD card today, so I tried mounting it on my PC in order to fix it or at least recover the data, which I have successfully done before when I had a similar issue.
However, the card appears to be completely blank (e.g. hexdump -C /dev/mmcblk0 doesn't output anything but zeroes). I would've thought that this meant the card's controller is broken or that it got accidentally wiped by the somewhat unreliable Android ROM I use, but the kernel still correctly detects the partitions, despite nothing else (blkid, fdisk -l, ...) being able to read anything from the card. lsblk reports two partitions of the right size on the card after inserting it:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 59.5G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part
└─mmcblk0p2 179:2 0 59.5G 0 part
...If I run partprobe at this point, the partitions are no longer visible afterwards. Here's the relevant kernel logs, partprobe doesn't add anything:
Jul 04 16:44:07 flex5arch kernel: mmc0: cannot verify signal voltage switch
Jul 04 16:44:07 flex5arch kernel: mmc0: new ultra high speed SDR104 SDXC card at address aaaa
Jul 04 16:44:07 flex5arch kernel: mmcblk0: mmc0:aaaa SL64G 59.5 GiB
Jul 04 16:44:17 flex5arch kernel: Alternate GPT is invalid, using primary GPT.
Jul 04 16:44:17 flex5arch kernel: mmcblk0: p1 p2When inserting a working card, partitions are detected much faster (with no GPT corruption warning) and the address is 0001 instead of aaaa.
Does anyone know what's going on with the card and why the kernel finds the partitions but then only shows a blank card? Is there any hope of recovering it without specialized equipment? I don't want to try formatting it just in case the data is still there.
Last edited by Ben Kerman (2020-07-04 15:07:54)
Offline
What happens when you try mounting the partitions? You said you tried mounting it to your machine but never provided the output of what happens when you try to mount.
I.E.
mkdir -p /tmp/mount1 && mkdir -p /tmp/mount2
sudo mount /dev/mmcblk0p1 /tmp/mount1
sudo mount /dev/mmcblk0p2 /tmp/mount2Does dmesg provide any useful output?
This is what it looks like when I plug in an SD card to my built-in SD card reader:
❯ sudo dmesg -w | grep --line-buffered usb
...
[ 9968.408236] usb 1-7: new high-speed USB device number 9 using xhci_hcd
[ 9968.558755] usb 1-7: New USB device found, idVendor=0bda, idProduct=0177, bcdDevice=77.11
[ 9968.558758] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9968.558759] usb 1-7: Product: USB2.0-CRW
[ 9968.558760] usb 1-7: Manufacturer: Generic
[ 9968.558761] usb 1-7: SerialNumber: 20121112761000000
...My initial instinct is that the "Alternate GPT is invalid" warning shouldn't actually impact anything since the primary GPT shows the correct partitions.
Offline
What happens when you try mounting the partitions? You said you tried mounting it to your machine but never provided the output of what happens when you try to mount.
Sorry about that. It doesn't work, probably since the system only sees a blank blockdev:
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.Does dmesg provide any useful output?
Exactly the same as the log messages from journalctl I posted in the OP:
[79832.503219] mmc0: card aaaa removed
[79838.684448] mmc0: cannot verify signal voltage switch
[79838.810883] mmc0: new ultra high speed SDR104 SDXC card at address aaaa
[79838.811480] mmcblk0: mmc0:aaaa SL64G 59.5 GiB
[79849.048503] Alternate GPT is invalid, using primary GPT.
[79849.048534] mmcblk0: p1 p2My initial instinct is that the "Alternate GPT is invalid" warning shouldn't actually impact anything since the primary GPT shows the correct partitions.
Yeah, the kernel does find the partitions somehow, but after that the entire card shows up as zeroed-out.
Offline
The SD card is probably gone. If you intend to rescue what you can, it is always advised to make a clone first and work with the clone since the card will deteriorate further the more you use it.
https://wiki.archlinux.org/index.php/File_recovery
Offline
A clone of what? As I said, the block devices are completely blank. What I'm mostly wondering about is how the kernel can even detect any partitions from that and if that could somehow be used to recover the data on the card if it's still there.
Offline
Yes the block devices as you said are completely blank but I'm just assuming that the files might just have been erased by whatever i.e. Android or others did. So it is also my assumption since the kernel can still see the partitions that somehow I think the partitions are intact but the filesystem is corrupt and therefore registering as blank. But of course these are all assumptions and others might have a better suggestion.
Offline
In Gparted, I sometimes see a warning like "data has been written but the system still uses old partition tables".
Maybe that's what happens to you? Maybe you need to reboot? Or plug it into a different USB port?
The hexdump output seems clear, but nevertheless, have you tried "nuking" the card with dd?
FWIW, I remember similar weirdness with an Android phone microSD card, some years ago...
Tried formatting the card in your phone?
Offline