Hmm... I just tried rebooting after about a day of having tried your fix, and so far the data survived. Btw, my /var/lib/collectd/rrd/* is still empty due to the previous fix I tried and I have not (yet) reversed that change.
Did you do systemctl daemon-reload after making the changes to /lib/systemd/system/folder2ram_shutdown.service?
I've forgotten the behavior in OMV4+Armbian, but in OMV5+Armbian, previous boots don't have entries in journalctl:
Apparently persistent journal is not necessarily enabled in /etc/systemd/journald.conf and I confirmed that /var/log/journal does not exist. https://askubuntu.com/question…ter-ubuntu-16-04-restarts
Is this intentional?
Thanks, I'll try ExecStartPre=/sbin/folder2ram -syncall.
I already tried the first solution of deleting/moving the /var/lib/collectd/rrd/localhost directory which contains .rrd files (much like in /var/lib/rrdcached/db/localhost) as mentioned at RE: error in syslog regarding rrdcached which I found since I had the same type of system log errors mentioned in RE: error in syslog regarding rrdcached. After this, the data seemed to survive a couple of test reboots and I thought it was solved, but after a day, rebooting again wiped out previous data.
BigBro Does your problem go away when you clear /var?
Mine does not look full:
Very frustrating. I still haven't found a solution to this.
Does anyone else have journalctl entries available only since the current boot? (on OMV5 installed on an SD card using Flash Plugin)
I made a post about Performance Statistics getting cleared on each reboot, but it's not just those stats but system journal entries too. Performance Statistics losing data after reboot
Quoting myself... since there is no reply about this problem, is the lack of persistence likely not due to OMV5?
Maybe the issue is with Flash Plugin? Or maybe it's something with rrdcached? Is there a proper way to reset rrdcached statistics data and journal?
If it's not related to OMV5 maybe I can ask on a different forum, if I can get a clue of what is likely responsible for the problem.
It turns out the Optimized Board Configuration for the HC1/HC2 is not prepared for kernel 5.4.y yet. So for now it is best to stick with the XU4 configuration for the full 2000 MHz and correspondingly improved performance:
http://ix.io/2k57
Use systemctl list-files --state=failed to see which services had issues. On my Odroid I have watchdog.service and wd_keepalive.service which fail with similar errors. I'm not sure if there are modules available for it.
To disable the watchdog in this case: sudo systemctl disable watchdog.service and sudo systemctl disable wd_keepalive.service
Does anyone else have journalctl entries available only since the current boot? (on OMV5 installed on an SD card using Flash Plugin)
I made a post about Performance Statistics getting cleared on each reboot, but it's not just those stats but system journal entries too. Performance Statistics losing data after reboot
Puzzling:
Before rebooting, I checked the timestamps on the .rrd files in /var/lib/rrdcached/db/localhost/* and they were recent. eg April 27. Then after rebooting, they are dated back to April 5.
Also, after timestamps update (every 15 minutes), the file size does not change.
How does this happen?
Since installing system updates around two weeks ago (~April 10), the Performance Statistics collected since then are not persistent after rebooting. Statistics before that date are still present.
When checked immediately after restarting, the statistics show "last update: April 10" and after refreshing there is no data from around that date to the present.
I also tried to check previous boot logs with: sudo journalctl -ef -b -1 which fails with: "Specifying boot ID or boot offset has no effect, no persistent journal was found." In the OMV GUI, the boot log has only the last boot, but the Syslog goes back beyond the current boot.
What has happened?
Possibly related to this reported issue with FlashMemory plugin: FlasMemory (Folder2ram) plugin issue
The tab has been removed. It is still possible to enable or disable from /etc/default/openmediavault. Another user asked the same question but I can't find the post now.
That would be me, and the post with the environment variables for several services is right here: RE: OMV 5.0 - finally out! :-)
Is there a reason the tab was removed from the GUI? It was useful.
I ran armbian-config's benchmark on my Odroid HC2 with Armbian and OMV5. I had applied the Optimized Board Configuration with armbian-config for the HC1/HC2. For those curious with the same or similar hardware, this may be useful as a reference point.
It is interesting to note that the passively cooled CPU seems to throttle to 1600-1700 MHz, while it is nominally 2000 MHz. I am also using the optional plastic case.
Just as a follow up, I'm happy with the upgrade to OMV5.
I didn't bother with /sharedfolders or symlinks and just used the /srv/... full path.
Updating settings does take a long time in some cases with OMV5, maybe up to nearly 5 minutes on an Odroid, but not always. Sometimes it's not quite so long. What I really like is that OMV5, whether due to Debian/Armbian or OMV5, is responsive much sooner in the boot process than OMV4. Within a few seconds, before booting is completed, it responds to pings, allows logging into the webgui, etc.
Boot time is also faster for me at ~45 seconds.
So far it's great!
Thanks, yes I started with Armbian and I already applied armbian-config's optimized board configuration for the HC2. I don't have a before/after on OMV5 but I have no complaints with 42s, it's faster than my desktop!
Updating the bridge chip firmware on the Odroid seems to have solved the problem for me: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update Now there is no more delay, and with OMV5 the boot time is 42 seconds!
In OMV4 the boot time was long due to fsck taking ~4 minutes to run on each boot. In OMV5, fsck timed out during the boot process after almost 2 minutes resulting in the service failing and the drive not getting mounted at all, and that caused all kinds of other errors in OMV.
I don't know if somehow original firmware (v173.1.0.1) got corrupted (since it worked fine for months before) or if the issue was something else, but at least it seems fixed now and has been fine over several warm and cold boots. A bonus is that the latest (v173.1.0.2) firmware adds a new feature: hot swap. 
One note: after updating the firmware a *cold* boot is required. The wiki mentions it, but I had forgotten and after initial warm reboots the drive was simply not detected. There were a few cold sweats until after a cold boot.
One great thing about OMV5, aside from the speedy boot time, is that ping responses, SSH, and the webgui are up really quickly, even before the boot process has completed. It quickly lets me know that it is working, which is reassuring for a headless system.
install usrmerge (sudo apt-get install usrmerge).
votdev Is this the "OMV recommended" solution? I have the same problem with NUT failing to start due to incorrect paths. Unlike the comment here, /bin is not a symlink to /usr/bin for me either.
I installed OMV5 from scratch by installing Armbian on an Odroid HC2 then used the OMV install script.
usrmerge indicates that the changes it makes are not reversible, so it would be good to know before doing this.
How should the watchdog be configured on the Odroid HC2?
Currently, the systemd fails to start the watchdog service with the error modprobe: FATAL: Module softdog not found in directory /lib/modules/5.4.28-odroidxu4 much like in this thread with the same issue for the RPi4: Raspberry Pi 4 Watchdog Not Working?
The systemctl errors are very similar to: https://forum.armbian.com/topi…g-not-found-in-directory/
The odroid wiki has some information but I'm not sure how to apply it for OMV:
QuoteODROID-XU3/XU4 kernel support s3c2410_wdt to control the Power Management Unit (PMU).
s3c2410_wdt driver is built-in so that watchdog daemon can configure the driver.
