Having had no problems with the venerable
Raspberry Pi I asked for a second one for my birthday.
I wanted this new one to be car based and also got a
wifi dongle and USB GPS(blog post pending) device.
But the fates were against me, I had also purchased a USB micro cable from
eBay and it is fair to say I chose the absolutely cheapest cable possible. After all USB cables are USB cables, right?
WRONG!
Repeatedly I found my new Pi dead, unable to boot and spewing all manor of error messages that could be in some way(sometimes very obscure) linked to file system corruption.
**I need to stop a moment and reiterate that last point REALLY BIZARRE issues, that after hours of tacking down were missing files or files that no longer ran, for instance 'sed' decided to become un-runnable, which screwed up all sorts of boot processes that then gave wacky error messages.**
I first blamed the SD card as it was also new and spent some time trying to prove it was
fake, but all the evidence pointed to it being genuine.
It did not help that SD cards and my
Linux systems have never been 100% reliable, but I tracked that down to the readers needing a powered USB hub even when plugged directly into the case.
On a positive note I did become and expert at backing up and restoring SD cards :p
First off, if it all goes wrong, try
fsck.ext4 /dev/sdc2
from a separate
linux machine, this seemed to do something but still got an error trying to mount it
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
but run it again and it asks me loads of questions (just say yes)
fsck.ext4 /dev/sdc2
and it can mount !!
hallelujah
Quickly as possible recover just the files you really can not live without.
And then trash it. Now I thought the 'trashing' bit would be easy, 'dd' is a block level operation, but after a few tries I ended up getting a Windows 7 machine remove all partitions and reformat it and only then did 'dd' produce a winning image.
Note: 'dd' gives no feedback while it is writing so I prefer 'dcfldd', just remember to set the sizeprobe to 'if' for the input and 'of' for output.
time dcfldd bs=4M if=/home/user/Downloads/raspberrypi/2013-02-09-wheezy-raspbian.img of=/dev/sdc statusinterval=1 sizeprobe=if
takes 30 mins
and so does
time dcfldd if=/dev/zero of=/dev/sdc statusinterval=1 sizeprobe=of
But that may shorten the life of your SD card.
Once I had the base image working(run the following on the Pi)
sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get install git-core -y
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo rpi-update
sudo reboot
now up to date the Pi's IP address had changed and rather than run
nmap I tried a little bash.
I knew the DHCP would give it a number in the 30-50 range and that the first 5 were taken.
for i in {36..50}; do ping 192.168.1.$i -W 1 -c 1 >/dev/null&&echo 192.168.1.$i; done
Pi found
Now I could start testing the power ...
To avoid running all that AGAIN, if I need to rebuild the SD card I can backup the Pi while it runs from
Linux with
ssh pi@192.168.1.38 sudo dd bs=4M if=/dev/mmcblk0 | gzip -c > raspberry_dd_4M.img.gz
or from a
linux card reader
dd if=/dev/sdc bs=4M | gzip > rasppi_4M.img.gz
and the obligatory recovery command
gunzip -dc /home/user/raspberry_dd_4M.img.gz | dcfldd bs=4M of=/dev/sdc
The progress bar option for dcfldd did not work here :(
Always try your recovering from your backup plan ...
Notice all the references to 'bs=4M' (Block Size) in the command and then filename, if you miss that then it does not work!
There is nothing worse than having a disaster and going to your backup, finding it does not work(a situation I have experienced first hand with DAT tapes in an enterprise).
So all this slowly led to the conclusion that something *Hardware* related was the issue.
There are many reports
such as this that indicate the problem is power related.
And there are an equal number of people retorting with "But my power supply IS rated for 5v" and then finding it really isn't.
So using the instructions
here I found that...
with my Motorola mains plug and the Motorola USB cable
Volts |
State |
4.92 |
boot |
4.89 |
ls -lR / |
5.05 |
halt |
Which ran with no problems.
Then again with the bad cable from
eBay
Volts |
State |
4.71 |
boot |
4.66 |
ls -lR / |
4.99 |
halt |
Which repeatedly "killed" my SD card.
Where "boot" was during the Pi booting up, then
ls -lR /
read the folder for every file on the root partition, this stressed the SD card and finally after shutting down the Pi OS so it was still receiving power and the Red LED was on but nothing else was drawing power in the "halt" state.
In hindsight it would have made sense to do some kind of write stress test as SD writes are known to draw additional power.
I got almost exactly the same results with another mains USB plug using the same cables.
Its all eBay's fault !!
(workman, tools ...)