I helped a user recover his nearly broken clipzip
We were still able to boot it to run the recovery firmware and replace the internal firmware
<CLIP ZIP RECOVERY PROCESS on RASPI -- Edited for length>
<Bilgus> get your PI up
<Bilgus> plug your extra usb stick
<Bilgus> and NOT the device yet
<Bilgus> do sudo fdisk -l and sudo lsblk
<Bilgus> get all the info for whats already on the system
<Bilgus> I'm guessing on the PI you are running NOOBs and that has some gotchas
<PI_USER> Yes im running raspbian
<Bilgus> when you get all that done start the ZIP as normal and do fdisk and lsblk again
<Bilgus> (after you plug it in)
<PASTED INFO>
~$ lsblk
sda 8:0 1 117G 0 disk
└─sda1 8:1 1 29.3G 0 part /media/pi/NEW VOLUME
sdb 8:16 1 3.7G 0 disk
└─sdb1 8:17 1 3.7G 0 part /media/pi/F634-E483
----------------------------------------------------------
~ $ sudo fdisk -l
Disk /dev/sdb: 3.7 GiB, 3933732864 bytes, 7683072 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: dos
Disk identifier: 0x6f20736b
----------------------------------------------------------
<PASTED INFO>
<Bilgus> yeah looks like you have sdb Lets make an Image of the drive on the ClipZip
<Bilgus> sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_disk.img"
<PI_USER> 7683072+0 records in 7683072+0 records out 3933732864 bytes (3.9 GB) copied, 634.81 s, 6.2 MB/s
<Bilgus> awesome no errors
<Bilgus> now you will disconnect the device run the recovery.sansa file and wait till the init message disappears and plug it in to usb
<Bilgus> do fdisk -l and lsblk again to see what they are now, sometimes it changes sometimes not
<Bilgus> you will need to wait till the WaRNING RECOVERY MODE message shows up and a bit after that before fdisk and lsblk will show anything
<PI_USER> the messege appeared immediately
<PI_USER> it's sdb again
<Bilgus> so now lets try dd again
<Bilgus> dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))
<Bilgus> yeah linux tends to move it back and forth but not always thats why its dangerous to assume
<PI_USER> yeah, like the letters in windows
<PI_USER> ok it's done, error ofc
<Bilgus> whats the message?
<PI_USER> pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))
dd: error reading ‘/dev/sdb’: Input/output error 3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 83.42 s, 18.7 kB/s
<Bilgus> ok try ..
<Bilgus> dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xbdf))
<PI_USER> sdb is gone, the device panic'd
<Bilgus> Give me a few I'm going to make a new recovery firmware for the clipzip with longer timouts
<Bilgus> compiling now i'll upload itwhen done
<Bilgus> https://www.mediafire.com/folder/pyydmx9m5zi1d/Recovery_Images
<Bilgus> its in the clipzip folder
<Bilgus> ok same thing again
<Bilgus> let me know when you get to..
<Bilgus> dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))
<Bilgus> don't forget sudo
<Bilgus> once thats done type sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<Bilgus> you will start the recovery FW wait for init message to disappear plug USb wait for warning message do sudo lsblk
<Bilgus> figure out drive do dd again replace X with your drives letter
<Bilgus> see if it completes without error
<Bilgus> in this firmware I upped all the timeouts and retries are way higher so hopefully its able to complete
<PI_USER> ok, dd is running
<PI_USER> pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000))
<PI_USER> dd: error reading ‘/dev/sdb’: Input/output error 3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 83.6416 s, 18.6 kB/s
<Bilgus> ok lets keep going
<PI_USER> ok
<Bilgus> sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<Bilgus> here we are removing sudo from the file you wrote
<Bilgus> hexdump "/media/pi/NEW VOLUME/clip_zip_hidden.img" -C -n 5000 > "/media/pi/NEW VOLUME/clip_zip_hidden.txt"
<Bilgus> paste the contents
<PI_USER> the zip panicked
<PI_USER> white screen
<Bilgus> nbd just disconnect it and long press power to turn it off
<Bilgus> we'll come back to it
<Bilgus> ok do the whole clipzip thing again this time we will tell dd to ignore errors
<PI_USER> ok
<Bilgus> <Bilgus> dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=noerror
<Bilgus> sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<PI_USER> dd is stuck in a loop
<PI_USER> it tries to do something, gives and error and repeats
<Bilgus> if its pulling a non existient drive it just pulls random data
<PI_USER> and the zip panicked
<PI_USER> 3040+0 records in 3040+0 records out 1556480 bytes (1.6 MB) copied, 233.664 s, 6.7 kB/s dd: error reading ‘/dev/sdb’: Input/output error
<PI_USER> this messege ran in loops
<Bilgus> try conv=sync,noerror
<Bilgus> dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=sync,noerror
<PI_USER> 3040+58400 records in 61440+0 records out 31457280 bytes (31 MB) copied, 103.197 s, 305 kB/s
<Bilgus> <Bilgus> dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) iflags=direct
<Bilgus> Email the dump to me <REMOVED>
<PI_USER> 7z does a good job, 1 mb instead of 32
<PI_USER> tho it is mostly 0's so it should be easy for it...
<Bilgus> that probably means lots of 0's
<Bilgus> I literally just opened the dump file in a hex editor and looked through it
<PI_USER> but those 0;s represent?
<Bilgus> the image has 00 where it couldn't read
<Bilgus> but there are places filled with 00 in the drive anyways
<Bilgus> so i compared the 00's in your file to the ones in my firmware dump
<Bilgus> ok so what we will try now is to pull just the parts we need to replace
<Bilgus> give me a second to build the dd command for you
<Bilgus> if player isn't already connected go ahead and do that now and get me the sdb sdc etc
<PI_USER> in normal firmware or recovery
<Bilgus> in recovery mode
<PI_USER> its sdb
<Bilgus> dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) skip=$((0xAA00))
<Bilgus> hopefully thats past the point it errors on
<PI_USER> pi@raspberrypi:~ $ sudo dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) skip=$((0xAA00))
61440+0 records in 61440+0 records out 31457280 bytes (31 MB) copied, 12.2217 s, 2.6 MB/s
<PI_USER> I dont see errors
<Bilgus> cool now sudo chmod 666 "/media/pi/NEW VOLUME/clip_zip_hidden.img"
<Bilgus> and finally hexdump -C -n5000 "/media/pi/NEW VOLUME/clip_zip_hidden.img" > dump.txt
<Bilgus> I can only skip whole sectors so I need to see where to start so we can copy over our new file
<PI_USER> done hexdumping
<Bilgus> and the clipZip didn't panic right?
<PI_USER> https://pastebin.com/DqSRm1mK
<Bilgus> download this if you haven't already
<Bilgus> http://www.mediafire.com/file/yibi1m6s589rq4j/clipzip4GB_RECOVERY_image32.bin
<PI_USER> ok, to the sd card?
<Bilgus> now this is the dangerous part
<Bilgus> no you want it on the pi
<Bilgus> you can put it on the USB stick if you must
<PI_USER> and how confident should I be
<Bilgus> just don't hit the usb cord and disconnect
<Bilgus> and 95% confident
<Bilgus> ok so first we need the path to your freshly downloaded .bin file
<PI_USER> media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin
<Bilgus> dd of=/dev/sdb if="/media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin" bs=512 skip=$((0x74FA)) seek=$((0xAA00))
<Bilgus> and tell me what it says, notice the of and if switched we are writing back a portion of the bin file to the good area on your device
<PI_USER> 31494+0 records in 31494+0 records out 16124928 bytes (16 MB) copied, 17.0948 s, 943 kB/s
<Bilgus> dd of=/dev/sdb if="/media/pi/NEW VOLUME/clipzip4GB_RECOVERY_image32.bin" bs=512 count=$((0x800))
<Bilgus> just get this done so danger is past
<PI_USER> 2048+0 records in 2048+0 records out 1048576 bytes (1.0 MB) copied, 1.00955 s, 1.0 MB/s
<Bilgus> once that is all done don't disconnect
<PI_USER> it's just 1 MB?
<Bilgus> we did the last part then the first part
<Bilgus> ok next at your leisure Send me a new dump dd if=/dev/sdX of="/media/pi/NEW VOLUME/clip_zip_hidden.img" bs=512 count=$((0xf000)) conv=sync,noerror
<Bilgus> I just need to check that everything copied right before you disconnect and reboot the player
<Bilgus> one extra thing lets dump a bit of the drive after the firmware area just to make sure the drive is still intact
<Bilgus> ok next at your leisure Send me a new dump dd if=/dev/sdb of="/media/pi/NEW VOLUME/clip_zip_drive_cur.img" bs=512 skip=$((0xF000)) count=$((0xf000)) conv=sync,noerror
<Bilgus> that should be the first 32 mb of the actual drive you see when the player isn't in recovery mode
<PI_USER> im back and the dd you told me to run is done, the zip panicked
<Bilgus> ok well no choice then, go ahead and disconnect and long press power
<PI_USER> loading of firmware file not found
<PI_USER> plug usb cable, thats the zip talking
<Bilgus> good sign though, ok plug in the usb cable
<Bilgus> actually do you have the multiboot fw on your flash card yet?
<Bilgus> so the .rockbox folder will be in the root of your sdcard
<Bilgus> its this one http://www.mediafire.com/file/a6ndfooqpdopo2o/MultiBoot_FW_ClipZip_5-22-17_rockbox-full.zip
<Bilgus> open the zip and copy the .rockbox folder to the root of the sdcard
<Bilgus> when done copying make a file on the sdcard root called rockbox_main.clipzip open it and put a single / in it save and close
<Bilgus> ok try restarting the player only a single '/' in the rockbox_main file right?
<PI_USER> the one on sd card? yeah
<Bilgus> ok try restarting it
<PI_USER> ok, starts normally
<Bilgus> go to debug menu
<PI_USER> debug menu?
<Bilgus> it worked but lets double check
<Bilgus> system>debug>boot info
<PI_USER> oh, ok boot data you mean
<Bilgus> just the fact you see that yes we booted from the sdcard
<Bilgus> as long as it says root <1> and crc: ok! its all good
<PI_USER> oh good!
<PI_USER> root <0>
<Bilgus> hmm might be because it didn't find the internal drive
<Bilgus> ok you want to redo the internal drive now?
<Bilgus> go ahead and shut down the player
<PI_USER> hahhaha it really doesnt show the internal storage in file manager
<Bilgus> eject the sdcard, reconnect after you turn it on
<Bilgus> plug in the clipzip to usb like normal
<Bilgus> and then do sudo lsblk
<PI_USER> its sdb again
<Bilgus> lets finish fixing the internal drive
<Bilgus> ok so now type mkfs.msdos -F 32 /dev/sdb
<PI_USER> mkfs.fat 3.0.27 (2014-11-12) mkfs.msdos: Device partition expected, not making filesystem on entire device '/dev/sdb' (use -I to override)
<Bilgus> I'm guessing we wiped out a bit of the internal drive table which not a huge deal but we will reformat it now to fix it
<Bilgus> ok so now type mkfs.msdos -F 32 /dev/sdb1
<PI_USER> no such file or dir
<Bilgus> being that its not setup with a partition we might have to force it with -I
<Bilgus> ok so now type mkfs.msdos -I -F 32 /dev/sdb
<PI_USER> done, no messege, like a good linux program
<Bilgus> ok power off player
<Bilgus> insert sd card
<Bilgus> power on and in file browser should have the internal drive
<PI_USER> looks like microsd0
<Bilgus> should have 0 and 1
<PI_USER> yeah have 0 which is empty and 1 which is sd
<Bilgus> the sansas consider the internal drive and the sdcard to be sd cards
<Bilgus> ok 0 is your internal drive now for words of warning
<Bilgus> open sdcard1
<Bilgus> long press and choose start here in the list
<Bilgus> now some warnings
<Bilgus> yes because its running from there but it will essentially hide the internal
<Bilgus> any file you copy to that internal drive rather than the sdcard is one step closer to a bricked device
<Bilgus> maybe not the next file maybe not the 100th but one of them will be the last file you ever copy to it
<Bilgus> you can boot into the OF now but it really hits that drive hard so try not to
<PI_USER> why, what does it do
<Bilgus> it does a lot of reads and writes
<PI_USER> its not like im recording data..
<Bilgus> the OF has a database of all files on the device thats why it always wants to refresh the darn thing
<Bilgus> each time it refreshes that database it reads every file and writes their names to another file
<PI_USER> is there a way to make rockbox not look at internal storage when making it's own databases?
<Bilgus> rockbox doesn't do that, and yes there is but no reason to
<Bilgus> booting from sd card makes it so rockbox doesn't use the internal drive
<Bilgus> rb only builds the database on demand and when stuff changes it just writes the differences to a new file
<PI_USER> so can I update now normally? with util or by hand?
<Bilgus> no you will need a sd card capable firmware to upgrade
<Bilgus> so yes you can upgrade by hand but it needs to be a special firmware
<PI_USER> and is there a way to easily compile such firmware on demand?
<Bilgus> Yes you can compile your own with the proper patches
<Bilgus> http://forums.rockbox.org/index.php/topic,51844.0.html
<Bilgus> I wrote up the instructions here
<Bilgus> its not easy but Its step by step
<PI_USER> is there an easy way to make it automatic? like with bash or something
<Bilgus> johnb I think did that you might ask him for his script
Rockbox Technical Forums
Topic: Clip+ lsusb Recovery Info (Read 739 times)