+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: Linux on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=114)
+--- Thread: Recover data from crashed emmc (/showthread.php?tid=11800)
Recover data from crashed emmc - S265 - 10-12-2020
Manjaro 20.08. KDE Plasma desktop
A while back the PBPro suffered intermittent locking behavior on the desktop. I was forced to reboot as no keyboard actions were having any affect. Upon reboot the logs indicted file system errors. Soon after this Manjaro would not boot at all. . . . . Forward two weeks . . . . . Manjaro 20.08 is booting on the SDCard.
The emmc device is present as /dev/mmcblk2. I wanted to check it for files that may be recoverable, but I could not mount it with the defaults. The output is
The device - 'doesn't seem to have a valid NTFS'. Should mounting mmcblk2 work with defaults? Any ideas on how to recover data on mmcblk2?
The plan is to copy my working SDCard Manjaro 20.08 across to this storage device as soon as I can. Naturally any files/data will be lost but I am prepared to wear this if necessary.
RE: Recover data from crashed emmc - ab1jx - 10-20-2020
How does NTFS get into the picture? Did a partition's type (just a byte I think) get changed? Does sfdisk -l show an NTFS partition now? Could have a corrupted superblock but it's probably ext4.
The original eMMCs seem to have started to fail, expect chaos. The super safe thing to do is probably copy the partition with dd to somewhere else then work with the copy. Several fdisk-type utilities can change a partition's type, I'd try to reset that to ext4 (on the copy). I don't think mount will mount it until it passes an fsck, you can specify an alternate superblock (number) to fsck. You can do a loop mount on a file made by dd and mount that volume almost like a normal partition.
RE: Recover data from crashed emmc - lewellyn - 10-20-2020
(10-20-2020, 05:09 PM)ab1jx Wrote: How does NTFS get into the picture? Did a partition's type (just a byte I think) get changed? Does sfdisk -l show an NTFS partition now? Could have a corrupted superblock but it's probably ext4.
The original eMMCs seem to have started to fail, expect chaos. The super safe thing to do is probably copy the partition with dd to somewhere else then work with the copy. Several fdisk-type utilities can change a partition's type, I'd try to reset that to ext4 (on the copy). I don't think mount will mount it until it passes an fsck, you can specify an alternate superblock (number) to fsck. You can do a loop mount on a file made by dd and mount that volume almost like a normal partition.
Wait... Isn't the PBP only like a year old? How are the eMMCs failing already? What's the wear like? (I found a quick-and-dirty script at https://electronics.stackexchange.com/a/525525 in case you don't have a better way to read the wear information.)
I have a PBP on my wishlist for when life feels normal to me again, but if I can only expect its eMMC to last about 20% as long as most eMMCs, I might have to reevaluate that.
RE: Recover data from crashed emmc - wdt - 10-20-2020
>Should mounting mmcblk2 work with defaults?
Not the WHOLE device, you have to mount partitions (eg, /dev/mmcblk1p1)
You can run fdisk on an image, then mount with the appropriate offset
eg sudo mount someimage existing-empty-mount-point -o loop,offset NNNN(K) (and maybe) -t type
testdisk if its really screwed up, you can run testdisk on an image
If fdisk seems to be "right" then run a fsck on PARTITION maybe more than once (until it ends without error)