Sansa Clip+: connects to PC but looks bricked

[sdf5]

Hi,

I have a Clip+ that looks bricked (no signs of life) but it is recognized when connected to a PC, see below. Any suggestions what I could try to get this Clip+ working?

Thanks


# echo "This is a NON-working Clip+"; fdisk -l /dev/sdc
This is a NON-working Clip+

Disk /dev/sdc: 4 MB, 4231680 bytes
1 heads, 9 sectors/track, 918 cylinders, total 8265 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
Disk identifier: 0xfbe2f9ff

Disk /dev/sdc doesn't contain a valid partition table

# mount /dev/sdc /mnt
mount: you must specify the filesystem type
# mount /dev/sdc /mnt -t msdos
mount: wrong fs type, bad option, bad superblock on /dev/sdc,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# less /var/log/syslog
...
Feb  6 21:18:36 tst kernel: [2599338.916156] usb 1-1: new high-speed USB device number 105 using ehci_hcd
Feb  6 21:18:37 tst kernel: [2599339.056329] usb 1-1: New USB device found, idVendor=0781, idProduct=6200
Feb  6 21:18:37 tst kernel: [2599339.056341] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb  6 21:18:37 tst kernel: [2599339.056349] usb 1-1: Product: M200Plus
Feb  6 21:18:37 tst kernel: [2599339.056354] usb 1-1: Manufacturer: SanDisk
Feb  6 21:18:37 tst kernel: [2599339.056358] usb 1-1: SerialNumber:         i **********
Feb  6 21:18:37 tst udevd[19256]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/pci0000:00/0000:00:12.2/usb1/1-1 1 105': No such file or directory
Feb  6 21:18:37 tst kernel: [2599339.061757] scsi67 : usb-storage 1-1:1.0
Feb  6 21:18:38 tst kernel: [2599340.063604] scsi 67:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
Feb  6 21:18:38 tst kernel: [2599340.065930] sd 67:0:0:0: Attached scsi generic sg2 type 0
Feb  6 21:18:38 tst kernel: [2599340.069041] sd 67:0:0:0: [sdc] 8265 512-byte logical blocks: (4.23 MB/4.03 MiB)
Feb  6 21:18:38 tst kernel: [2599340.070047] sd 67:0:0:0: [sdc] Write Protect is off
Feb  6 21:18:38 tst kernel: [2599340.070058] sd 67:0:0:0: [sdc] Mode Sense: 04 00 00 00
Feb  6 21:18:38 tst kernel: [2599340.071996] sd 67:0:0:0: [sdc] No Caching mode page found
Feb  6 21:18:38 tst kernel: [2599340.072044] sd 67:0:0:0: [sdc] Assuming drive cache: write through
Feb  6 21:18:38 tst kernel: [2599340.082074] sd 67:0:0:0: [sdc] No Caching mode page found
Feb  6 21:18:38 tst kernel: [2599340.082086] sd 67:0:0:0: [sdc] Assuming drive cache: write through
Feb  6 21:18:38 tst kernel: [2599340.094582]  sdc: unknown partition table
Feb  6 21:18:38 tst kernel: [2599340.106072] sd 67:0:0:0: [sdc] No Caching mode page found
Feb  6 21:18:38 tst kernel: [2599340.106084] sd 67:0:0:0: [sdc] Assuming drive cache: write through
Feb  6 21:18:38 tst kernel: [2599340.106092] sd 67:0:0:0: [sdc] Attached SCSI removable disk
Feb  6 21:20:25 tst kernel: [2599447.403267] EXT3-fs (sdc): error: can't find ext3 filesystem on dev sdc.
Feb  6 21:20:25 tst kernel: [2599447.427099] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Feb  6 21:20:25 tst kernel: [2599447.428165] FAT-fs (sdc): bogus number of reserved sectors
Feb  6 21:20:25 tst kernel: [2599447.428184] FAT-fs (sdc): Can't find a valid FAT filesystem
Feb  6 21:20:25 tst kernel: [2599447.435087] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Feb  6 21:20:25 tst kernel: [2599447.436165] FAT-fs (sdc): bogus number of reserved sectors
Feb  6 21:20:25 tst kernel: [2599447.436182] FAT-fs (sdc): Can't find a valid FAT filesystem
...

[[Saint]]

The 4MB storage being presented is the classic symptom of a bricked Sansa AMS player.

All we know about the "recovery" (you'll see why I refer to that in quotes later on) procedure for these devices is listed in the SansaAMSUnbrick wiki page.

The wiki page seems to suggest that the procedure is straightforward, or repeatable, or reliable. It isn't. In fact, its none of those things. Hence the quotation on "recovery".

If you decide to attempt this procedure please make sure to do so while actively communicating with us on our IRC support channel for live, realtime assistance. If I am present and available at the time I would be happy to walk you through the process.


[Saint]

[sdf5]

Thanks, I'll see what I can do.