I use a nanopi neo 3 for basic home services for about 2 years. It runs Dietpi and have a handful containers running on it using docker/portainer. I keep Dietpi updated.
I always experienced random lock-ups. Once every 2 months on average I think. At first I thought this was related to power surges ( info from a home electricity power usage logging container) so I installed a tiny UPS device ( lipo battery charger/ups) to rule out the power surges.
However it made not much difference.
I still have the random lock-ups.
Luckily the system recovers well until now after a lock-up and a power cycle. The partial loss of the home electricity logging is not crucial for me.
I would like to add some control function for home battery storage to control charging and discharging the battery. But with the random lock-ups I find this setup not reliable enough to go on with it.
I also have tried to preserve a few previous bootlogs but I could not figure out how to get that happening. Although I do not expect that older boot logs will show much info to help. But you never know…
My system runs on USB but boots from SD as described here:
I also assume I have ruled out that a bad power supply may be the cause. The NPN3 will even run when powered from a USB hub but it is now powered from a tiny lipo UPS/charger. Running heavy tasks: e.g. zip7 compression using 4 cores for 30 minutes works well. Overheating is no problem either because a regulated cooling fan, I use a cron-job for it, is installed. It does it’s job as expected.
Applications running in docker:
dsmrreader (home power usage logging)
database (postgres) for previous
whoogle ( rarely used)
Pihole
wireshark server for remote access ( I never had a lock-up related to remote access)
filebrowser
I have no services running on Dietpi natively, only a cron-job to regulate the fan.
The random lock-ups don’t seem to be related to acces or program tasks, but I cannot rule this out 100%
I know this “problem” is not very well prescribed with this, but I have no additional information that seems to be related to these random lock-ups.
Without an error message or log, it is almost impossible to determine the cause. Unfortunately, on a standard system the log is deleted after a reboot. You can therefore try to activate permanent logging. There may be some information after the next system freeze.
persistent system logs:
dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall
Then you can check system logs via:
journalctl
which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:
I had tried before to preserve previous boot logs using the generic Linux way, but that did not work.
With your info I will try again.
I do not expect storage issues. I have a 240Gb USB disk with a 20Gb rootfs partion , currently only 17% of it used. All data including docker files are stored on the remaining 220GB partition. (also only 17% used…)
It may take a while before the next lock-up will happen, however it may also manifest itself tomorrow
The problem appeared harware related. I have 2 Nanopi Neo3 boards. The one that randomly locked up had a damaged TTY2 port ( normally configured as deafault serial debug port). Initially I could not connect to it with the baudrate 1500000. Trying to solve this I assume I somehow damaged the tty2 connection, reversed polarity, misconfigured GND/TX/RX whatsoever. I managed to reconfigure the debug tty to tty1 in dietpi.txt. Later in time I also found a way to use the default baudrate 1500000. That appeared to be a software limitation of the terminal emulator program Gtkerm I used, but an updatede version of that could handle the higher baudrate without complaints. Comparing both Nanopi’s I had found that the tty2 port on 1 of the nanopi’s did not function anymore. And that was the one that locked-up. The 2nd one is running without problems for a few month now. No software problem, but hardware. Another issue might be the USb-tty convertors I have. I have a few different models and they all behave a bit different. That contributed to the complexity trying to use the default baudrate of 1500000. I am quite sure that the different circuitry in the various usb/tty converters may have caused the tty2 port to become damaged. Connecting one of them to a powered host system somtimes lockup the host. That did never happen with other adapters. Also the led’s on one of the adapters would light up a little every few seconds. I suppose that the circuitry charges itself from the TX RX lines from the host and then the led lights up causing a voltage drop and so on.
Anyway, I now use the damaged Nanopi as a development device to try out new things before a add them to the stable “production” Nanopi server.
