I had an issue where my device would reboot after a couple of weeks, sometimes longer sometimes less but on average it was about 2 weeks. But as it was rebooting it was hanging, so effectively it would fail and never come back up.
This drove me mad for 2 or 3 months but eventually I managed to work it out. I was powering my O2+ via USB so I plugged in a USB power monitor and found that the device was crashing and as the boot sequence brought up the WiFi it would hang. We know that loading the WiFi service increases load while it scans for an AP so this was not unexpected. Eventually I worked out that the WiFi connection was dropping out during normal operation due interference to the AP, typically that was not an issue because the O2+ would automatically reconnect so it would go unnoticed. However when when the O2+ was working hard processing a stream of data from an SPI data source and at the same time the AP disconnected, the O2+ would crash. As it came back up and loaded the WiFi stuff it would then hang.
We did a few things to fix the issue. 1) Move the AP, it was close to a fluorescent light and when it blinked the AP would glitch; 2) Replaced the power supply of the o2+ with higher wattage.
That fixed the issue but didn't fully explain it, but we were busy with other things so I was happy My guess is that it was a load issue, restarting wifi while processing data required more juice than was available so the device would crash. Then when it was rebooting it was running out of juice starting WiFi because it was already loading another module that was consuming a lot of juice connecting to a sensor that was left in an undefined state due to the initial crash.
The moral of the story is ... don't be stingy with your power supply
How did we monitor the $22 USB power monitor? We took an old laptop, pointed its camera at the USB monitor so we had a video of the display, since the laptop was old it had only about 128GB of SSD so video was on a loop of about an hour. Then we had a bash script that pinged the O2+ every minute and if ping failed it sent me an email and stopped the camera so we didn't overwrite the video. A bit like gaffa tape and bits of string but it was what we had to work with at the time
While OpenWrt is a single user system, you can create additional users so you don't have to disclose the root user password. You can add the user by editing /etc/passwd and /etc/shadow or you can install the useradd package:
opkg install shadow-useradd
Now add a new user named "admin", but we don't want them to have shell access:
useradd admin -d /var -M -s /bin/false -p mytemporarypassword
The password is added in cleartext so you need to change it using the command:
passwd admin
Follow the prompts to set your password then you can confirm the new user has been added as required:
cat /etc/passwd
cat /etc/shadow
Since OnionOS uses ubus via rpc we need to add the user to the rpc user list. The configuration file is /etc/config/rcpd, but you can use uci commands to add the user:
uci add rpcd login
uci set rpcd.@login[-1].username='admin'
uci set rpcd.@login[-1].password='$p$admin'
uci add_list rpcd.@login[-1].read='*'
uci add_list rpcd.@login[-1].write='*'
uci commit rpcd
The username must match the username we just created and the structure of the password field causes the rpc daemon to use the system password we just created.
The "read" and "write" fields is set to an asterisk indicating that the user will have unrestricted access, the same as the root user.
You can confirm the new user had been added using a uci command:
uci show rpcd
rpcd.@login[0]=login
rpcd.@login[0].username='root'
rpcd.@login[0].password='$p$root'
rpcd.@login[0].read='*'
rpcd.@login[0].write='*'
rpcd.@login[1]=login
rpcd.@login[1].username='admin'
rpcd.@login[1].password='$p$admin'
rpcd.@login[1].read='*'
rpcd.@login[1].write='*'
Now restart the rpc daemon:
service rpcd restart
You can now login to OnionOS with the same functionality as the root user has, but the user has no console access.
@cyberai pls try running the checkCamera.py Example Python Program and posting the command line output and screenshots of the output.
This will give us a better idea of what's going on.