Awesome, glad it seems to be working now. It appears it was an issue with the long style option for overlay only working on some systems for some weird reason. I’ll look into that some more. But for now it’s fixed by using the short option.
I’ve also updated the code one more time today to fix the exception mentioned by @Lionello_Marrelli.
I’ll build and push a new image today so the correct code is cached in the image as well.
Hi @ndye,
I am afraid the issue still persists or occurred again. I just rebooted the instance after two days and the data is gone again.
Same behavior as before. In the log I see an input/output error when zram tries to sync: zram-config.log (818.8 KB)
Best,
Florian
Hi, just tested by rebooting a app. 6 days running test system - based on Openhabian 1.9.1 64Bit on Rpi 4, including above mentioned updates.
No Problems, persisance data remained ok. (I can only tell for my system…)
Seems that on your system zram was ok till 28th Aug. - Logs and persistance data was moved correctly
But after restart on 29th Aug (see in in zram-config.log: zram-config stop 2024-08-29-20:27:32-CEST ) it fails… to access the zram folders (see in zram-config.log:: ls: cannot access '/opt/zram/zram3/upper': No such file or directory)
So log file does not show the initial error (–ignore-mounted).
Sorry no idea why this happened…too less knowledge.
Rg, Bert
Good catch…
Looks like a permission problem on the filesystem. I fixed the file permissions with `openhabian-config`` and after a reboot everyhting’s behaving as expected.
Best,
Florian
You may or may not be having 3 zram-mounted file systems defined in ztab, usually it’s only 2, logs and persistence (not counting swap).
Mhm, this is the output from zramctl:
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 1G 16K 110B 80K 4 [SWAP]
/dev/zram1 zstd 750M 681.7M 34.4M 43M 4 /opt/zram/zram1
/dev/zram2 zstd 350M 57.6M 2M 6.2M 4 /opt/zram/zram2
/dev/zram3 zstd 1G 578M 68.5M 76.4M 4 /opt/zram/zram3
Folders are there as well:
zram3/upper: logs
zram2/upper: persistence (influx)
zram1/upper: persistence (RRD4J, MapDB)
Anyways, after fixing permissions I tried rebooting today and did not encounter the issue again. Will watch closely and retry in a couple of days.
OK, sounds good, just let me know
Hi @ndye,
I again have a problem with zram. Interestingly, it does not appear on every reboot. Last reboot was on Sep 18, zram sync worked accordingly, all data was persisted.
On Sep 28, I did another shutdown with sudo shutdown now. After I booted again, the data for the past 10 days was lost, and I see errors in the zram-config log:
zram-config (2).log (9.3 KB)
Can you please take a look?
Thanks,
Florian