billybangleballs

I understand what you are saying Igor, and I am appreciative of all the work you do to support the community. My reason for posting in the first place was not to try and get free technical support, but just to ask if anyone else has had a similar problem and what caused it. I am quite capable of downloading a new image and writing it to a tf card, but doing that doesn't answer the question as to why it broke in the first place. I still have no idea what changed, whether it was the unattended-update or the tf card is worn out because it is two years old. I have solved many problems in the past by reading forum threads and learning from other peoples experiences. I can't think that this thread is going to help many people though. Unless the answers, 'sh*t happens', or 'you need an upgrade' are helpful to someone. Conclusion. My Orange Pi Zero, which was commissioned two years ago, ran very reliably with an uptime of over a year, and then started crashing for reasons unknown to me. I'm fairly sure that the reasons for this do not include not running Buster and/or a 4.x kernel, but are more likely to be that the tf card is worn out or the auto-update has updated itself to a broken state. I am going to replace the tf card, install Armbian and see if I can get it to run for another year or two without breaking and I'm sorry I've wasted everyone's time by writing about it.

I could start again with a new install of Armbian or go back to using a raspberry pi, but the whole point of the OP0 was a cheap, fit and forget, device, I didn't realise that it was secretly modifying itself over time. I would like to understand what went wrong, because obviously something doesn't go from over a year uptime to crashing every three or four days for no reason. I'm currently blaming the 'unattended-upgrade' for breaking things, but it may well be something else.

Does this help?

I have an Orange Pi Zero that had an uptime of well over a year monitoring the output of some solar panels and the state of charge of a battery. It then switches a couple of relays in response to these measurements. It has been really reliable for 2 years, never crashing or rebooting until now. At the beginning of September it started to stop working, it has no monitor or keyboard, only a cat5 cable, so when I say stop working, I mean it stops logging to the nfs drive, stops switching the relays, stops responding to pings and any ssh sessions timeout. It does this every few days, around 6:30 am, and I then have to power cycle it to get it to work again. Did some unattended-upgrade during August, break something that could be responsible for this errant behavior? The fact that it stops working around the same time of day each time, makes me think it is a software rather than a hardware issue. It logs to another machine on the network, but there is nothing in these logs that suggest there is a problem. It randomly writes 'PHY: gmac0-0:00 - Link is Up - 100/Full', to the kernel log, but it has always done this. Can anyone think of a software change that could cause this?

Yeah, a wiki, http://www.orangepi.org/download/orange_pi-zero-v1_11.pdf maybe this is more like you are wanting.

https://linux-sunxi.org/Orange_Pi_Zero

https://raspberrypi.stackexchange.com/questions/4569/what-is-a-pull-up-resistor-what-does-it-do-and-why-is-it-needed I don't know if a pull-up resistor will cure your issue, or whether it is something else entirely, but it was the first thing that sprang to mind when I read your original post.

http://linux-sunxi.org/GPIO will be a good place to start

You don't say much about the mechanics of your interfacing, are you pulling the GPIO to a known level with a resistor, or just letting it float around aimlessly, hoping that the software will be enough? The LCD will not provide enough load to provide this service. A 10k resistor between the pin and vcc or gnd will maybe cure your problem.

My OPi0 hovers around 40°C all day, no heatsink, no real load, just toggling i/o in response to serial port input from an arduino. If I put my finger on the H2+ it feels warmish, but just the act of pressing my finger on it reduces the temperature to 32°C. There is no heatsink, ambient temperature is low 20's. ___ ____ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/ Welcome to ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 0.02 Up time: 4 hours Local users: 2 Memory usage: 20 % of 241Mb IP: 192.168.0.35 CPU temp: 40°C Usage of /: 69% of 1.7G The PSU is a homemade affair that outputs 5v on the nail with enough current capacity to weld with

Thank you. Is there a place where all my questions are answered already? I don't want to annoy people on the forum with my n00bness.

I don't know if this is something I have broken or not, but I have a \var\log and a \var\log.hdd both identical and both being updated. Where should I be looking to rectify this duplication? ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i OrangePiZero

Thanks for taking the time to reply, I feel a little more educated now. Last week I didn't know the difference between legacy and mainline but it is becoming clearer.

Of the 10 columns of output, only 4 seem to be working. Time, CPU Frequency, Load & Temperature. The other 6 columns seem wrong. I'm running Armbian_5.25_Orangepizero_Debian_jessie_default_3.4.113.img Running minerd --benchmark on the console and armbianmonitor -m in a ssh session produces this :- Time CPU load %cpu %sys %usr %nice %io %irq CPU 06:25:10: 240MHz 0.13 1% 0% 0% 0% 0% 0% 47°C 06:25:16: 1200MHz 0.36 1% 0% 0% 0% 0% 0% 64°C 06:25:21: 912MHz 0.65 1% 0% 0% 0% 0% 0% 68°C 06:25:26: 912MHz 0.92 1% 0% 0% 0% 0% 0% 65°C 06:25:31: 912MHz 1.17 1% 0% 0% 0% 0% 0% 69°C 06:25:36: 912MHz 1.39 1% 0% 0% 0% 0% 0% 66°C 06:25:42: 768MHz 1.60 1% 0% 0% 0% 0% 0% 67°C <snip> 06:48:45: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:48:51: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:48:56: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:49:01: 768MHz 4.08 2% 0% 1% 0% 0% 0% 72°C 06:49:06: 768MHz 4.07 2% 0% 1% 0% 0% 0% 72°C 06:49:11: 768MHz 4.07 2% 0% 1% 0% 0% 0% 72°C 06:49:17: 768MHz 4.06 2% 0% 1% 0% 0% 0% 72°C 06:49:22: 768MHz 4.06 2% 0% 1% 0% 0% 0% 72°C <snip> Killing minerd causes the load and temperature to drop back to normal. 06:56:44: 768MHz 4.08 3% 0% 2% 0% 0% 0% 72°C 06:56:49: 768MHz 4.07 3% 0% 2% 0% 0% 0% 72°C 06:56:54: 240MHz 4.06 3% 0% 2% 0% 0% 0% 71°C 06:56:59: 240MHz 3.74 3% 0% 2% 0% 0% 0% 64°C 06:57:05: 240MHz 3.44 3% 0% 2% 0% 0% 0% 62°C 06:57:10: 240MHz 3.16 3% 0% 2% 0% 0% 0% 61°C 06:57:15: 240MHz 2.91 3% 0% 2% 0% 0% 0% 57°C 06:57:20: 240MHz 2.68 3% 0% 2% 0% 0% 0% 52°C 06:57:26: 240MHz 2.46 3% 0% 2% 0% 0% 0% 49°C 06:57:31: 240MHz 2.27 3% 0% 2% 0% 0% 0% 47°C 06:57:36: 240MHz 2.08 3% 0% 2% 0% 0% 0% 46°C 06:57:42: 240MHz 1.92 3% 0% 2% 0% 0% 0% 47°C 06:57:47: 240MHz 1.76 3% 0% 2% 0% 0% 0% 48°C 06:57:52: 240MHz 1.57 3% 0% 2% 0% 0% 0% 46°C The CPU throttling is working fine, but I'm sure all those 0%'s can't be right. The CPU is going as fast as it can without melting, yet it only registers at 2-3%. Is this normal?

I found that https://www.armbian.com/donate/?f=https://dl.armbian.com/orangepizero/Debian_jessie_default.7z worked OK for me.