Short description:
I opted to install Dietpi with Mate desktop. I also installed TigerVNC Server. Computers on the local LAN can access this device via their VNC clients such as TIghtVNC etc. This device is left on and connected 24/7, without a video monitor connected. Dietpi comes with Firefox 78.15.0esr(64-bit). When Firefox is left running, at some point in time, the Odroid N2+ stops responding and without notice. The only way to recover is to do a cold boot.
Detail:
I have tested this multiple times, Firefox appears to be the point of failure. To be very clear, Firefox might be left running with a basic web page, no extra memory is being consumed that I can see. Leaving a terminal open running htop will never crash the device, but leaving Firefox running always does. Is there some way of determining in a log file why this happens? I do not want to destroy the sdcard by these sudden cold reboots required. Although I might try Chromium, I prefer FireFox as Noscript and uBlock are critical for me.
I have stress tested the device for over 12 hours and it does not fail! But Firefox does cause it to lock up and die when left running. To specify again, the device is being run as a VNC server on a LAN. I do not know if this problem is specific to this version of Firefox and I cannot see that there is any method in Dietpi to install a different/newer version of Firefox to see if this problem persists.
If somebody can give me some direction here that would be of great help.
There is no specific Firefox version on DietPi. It is the default version provided by Debian repository via apt packages. The version installed should be latest available.
Probably you can try starting Firefox from terminal emulator to track STDOUT/STDERR output, though when it crashes I guess you do not see the console on VNC client anymore? Probably it works to redirect output to a file instead:
firefox &> firefox.log
Also system logs may reveal the issue. They need to be made persistent, either by enabling full logging via dietpi-software (then checking /var/log/syslog and probably /var/log/kern.log) or uninstalling RAMlog and making system journal persistent:
dietpi-software uninstall 103
reboot
# after reboot
mkdir /var/log/journal
systemctl restart systemd-journald
# after crash
journalctl
Probably you can try starting Firefox from terminal emulator to track STDOUT/STDERR output, though when it crashes I guess you do not see the console on VNC client anymore? Probably it works to redirect output to a file instead:
firefox &> firefox.log
Also system logs may reveal the issue. They need to be made persistent, either by enabling full logging via dietpi-software (then checking /var/log/syslog and probably /var/log/kern.log) or uninstalling RAMlog and making system journal persistent:
dietpi-software uninstall 103
reboot
# after reboot
mkdir /var/log/journal
systemctl restart systemd-journald
# after crash
journalctl
No I don’t suggest that. It’s exactly the opposite. The version installed by DietPi is the same as you would install via apt. Because this is what DietPi does. We install the version from apt repository already. It’s exactly the same.
So thus you are suggesting that uninstalling via dietpi-software and then re-install Firefox via dietpi-software will install the latest Firefox (ver 95+)? Sorry this is not clear to me. Could you please be explicit as to how you would upgrade Firefox via the cmdline?
Ahh…that makes more sense to me! I am writing this on another Odroid N2+ which is not based on Dietpi, it is Ubuntu 18.04.5 LTS aarch64, and yes, Firefox has been “automagically” updating itself as per Mozilla edict for some time now. I think what you are saying is that the Dietpi repositories are “stuck” at Firefox 78.15.0esr(64-bit), at least that was the version that was installed by the Dietpi package (7.8-7.9?) back in December 2021.
Unlike the x86 Linux setups, where I can download directly from Mozilla the latest version of Firefox and install it in a separate directory, I have not found that same facility with ARM distributions. Firefox 78.15.0esr(64-bit) is esr, meaning no more upgrades, at least as far as versions are concerned, right?
DietPi don’t have an own repository. We use the official Debian or Raspbian repository. We don’t have any influence on the version provided. Current version on Buster and Bullseye seems to be 78.15.0esr-1. The next version 91.5.0esr-1 is available on Debian Bookworm.
My suggestion was to enable persistent system logging by uninstalling DietPi-RAMlog (software ID 103) and making system/journal lops persistent (mkdir /var/log/journal). So you can check the system logs from before the crash.
After a few weeks of 24/7 testing, it seems that the upgrade to v 8 of dietpi “Buster”, through the ssh console solved this problem!
I will consider “Bullseye” soon, when “forced” to. Rather conservative person here! I would hate to re-customize my whole setup again, which is just a few months old. Fingers crossed here, seems to be solid now.
It is based on Linux 5.10 by Armbian with modern U-Boot etc, built competely from scratch via debootstrap.
So far I got only positive reports, though some special features like CEC may not work.
Sadly the kernel cannot be upgraded on the old image as the new bootloader expects a single ext4 partition image, different boot configuration files etc.
Apologies for may mix things but I can create new post. Feel free to edit move.
1)What VNC did you installed I have realVnc, but it look like it is not available in Diet-Pi for Odroid N2+ for Buster and I got an armV7 version.
On DietPi, RealVNC is available on Raspberry Pi device only. On all other device we have it disabled because it require a license to be able to work. Means, you would need to install it manually on Non-RPi SBC yourself.
The new image has been moved to stable downloads already, so your second link is correct.
RealVPC is not free, also not free-in-beer. Only the RPi Foundation has a certain agreement to provide a pre-licensed package via their own APT repository. We hence cannot provide it on non-RPi systems, at least not functional OOTB with our VNC startup service and options.
For x86 systems you could download a package from RealVNC directly: https://www.realvnc.com/en/connect/download/vnc/linux/
But it won’t allow any remote connection until you add a subscription key and it is not available for non-RPi ARM SBCs.
I tested both intensively, RealVNC and the entirely FLOSS and free-in-beer TigerVNC, and I cannot see any benefit RealVNC offers, aside of when using the additional VNC® Connect subscription (as well required on RPi then) to enable ondemand virtual desktop spawning. Otherwise, just use TigerVNC.
Hi MichaIng
Thanks for your reply and explain about RealVnc agreement
$> dietpi-software list | grep vnc
ID 120 | =0 | RealVNC Server: desktop for remote connection | +desktop DISABLED for Odroid N2 (aarch64) | https://dietpi.com/docs/software/remote_desktop/#realv
I was testing VNC. But as far as I know and let me know if I am wrong.
TigerVNC has no user password encrypt. In theory, you can put it behind ssh port but I was not be able to do it.
TigertVNC needs an IP and port open. It means if your server is behind dynamic IP. you can have more problems to connect
Yes I have ducks to map my dynamic IP to a domain, but the dns propagation could take time. And it is another point of failure.