Pine64 Dead

[sdf_iain]

Suddenly I'm getting nothing from my Pine64.  Yesterday it was happily chugging along.  Today its putting out nothing but heat and red light (from the led next to the power jack).  How do I verify that it's dead?  What are the chances it can be replaced?

[pfeerick]

Suddenly I'm getting nothing from my Pine64.  Yesterday it was happily chugging along.  Today its putting out nothing but heat and red light (from the led next to the power jack).  How do I verify that it's dead?  What are the chances it can be replaced?

I had the same thing a few days ago, and it seems the microSD was corrupted. Might be worth grabbing another microSD and writing a fresh image on it to see if that's the case (or wipe the current one if you're not bothered about loosing what's currently on it). 

Other thing you can do if you have a 3.3v USB to serial converter handy is to connect to the GND, RX and TX ports on the EXP header, and see what output you get from the serial console (ANSI, 115200 baud).

[sdf_iain]

I hosed the sd card while trying to mount it to more lazily put in a replacement in place. I'll try a fresh install tomorrow and see what I get.

[sdf_iain]

I hosed the sd card while trying to mount it to more lazily put in a replacement in place.  I'll try a fresh install tomorrow and see what I get.

Seems renewing the sd Card has revived my Pine64 (it was not dead).  I guess that's what I get for running BOINC on it.  back to just doing DHCP and DNS for me.

[MarkHaysHarris777]

Another tip, you can backup the SD card by reversing the burn process. Once I get my SD cards working the way I want them to I use the DD command to write the card back out to my image server. If I blow a card I'm back up and running without a hitch in about twenty minutes.

[pfeerick]

Another tip, you can backup the SD card by reversing the burn process.  Once I get my SD cards working the way I want them to I use the DD command to write the card back out to my image server.  If I blow a card I'm back up and running without a hitch in about twenty minutes.

That is really good advice! I do the same after making any major changes to the pine64 configuration, as you just never know when something bites back! I use 'USB Image Tool' on windows to the the backups as it is easy to use and has the ability to both save to and read compressed (zipped) image files, making the 4/8/16GB images a bit easier to manage

MicroSD cards  (and their full sized cousins) have a limited number of write cycles meaning that constantly writing data to the MicroSD card makes it more and more likely that it will pack up. A lot of them do have wear levelling to ensure the same block of memory isn't continuously written too, which makes them last a lot longer. However, anything from a freak cell failure in just the wrong spot, or a power outage causing file system corruption can ruin you day. With these SoC boards and microSD cards, a backup of a acceptable recovery point is essential! I've had one board going for about 3 years now (not a pine, a different one), and thankfully it seems to be coping with 24x7 duty as a network share drive with regular usage without any major issues. I still have a backup of the boot microSD ready for when it finally fails, just in case

[sdf_iain]

Another tip, you can backup the SD card by reversing the burn process.  Once I get my SD cards working the way I want them to I use the DD command to write the card back out to my image server.  If I blow a card I'm back up and running without a hitch in about twenty minutes.

I'm not sure I can write a card in 20 minutes, but I might do that.  My main issue is that the pine is running necessary network infrastructure (dhcp and dns), so the wife and kids get grumpy when I take that away


And pfeerick, you'll probably get better compression if you compress with xz or bzip2.  dd will read from standard in if you leave out the if argument i.e.

Code:

bzcat image.bz2 | dd of=/dev/sdcard bs=1m

or

Code:

xzcat image.xz | dd of=/dev/sdcard bs=1m

You could also easily create compressed images:

Code:

dd if=/dev/sdcard bs=1m | bzip2 - > image.bz2

or 

Code:

dd if=/dev/sdcard bs=1m | xz - > image.xz

You could get crazy and include -9 in the compression arguments if time isn't an issue, but space is.  In fact, I might do that... we just need some "down time".

[MarkHaysHarris777]

Another tip, you can backup the SD card by reversing the burn process.  Once I get my SD cards working the way I want them to I use the DD command to write the card back out to my image server.  If I blow a card I'm back up and running without a hitch in about twenty minutes.

I'm not sure I can write a card in 20 minutes, but I might do that.  

The way you do it in twenty minutes is by only writing what needs to be written. In addition to compressing, you also only write a 'smaller' partition size.  Before I store the card I use tar (via standard in standard out) to write the contents of the rootfs to a smaller partition size;  then I compress | DD that !

tar -cvf  -  -C  <directory>  <subdirectory>  | tar  -xvf  -

That command will pass the tar through stdin | stdout and will preserve all the permissions to boot. So you can put your 32Gb partition into a 6Gb space (or whatever) and not have to write out an entire 32Gb SD card.  

When you restore the card, you of course need to expand the partition size (either with lennyraposo's resize_rootfs.sh script , or with gparted )

[pfeerick]

And pfeerick, you'll probably get better compression if you compress with xz or bzip2.  dd will read from standard in if you leave out the if argument

Yeah, true... might have to  use linux for the backups for that though xD... or the new linux subsystem in Windows FWIW.

That has me thinking... I bet 7zip could shrink that down a bit more still.... then again, I'm pretty happy with my 673MB images of a 8GB memory card! :-O 

Many thanks for the pointers though... I will probably give that a try at some point. That plus knocking some sense into dd so it give some progress stats...