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
Hi all,
Because I could not get zram to work reliably and it occasionally failed to sync data on reboot on a PI5, I solved it differently.
/var/lib/openhab/persistence to the SSD/var/lib/openhab/persistence/etc/ztabThat way persistence data is written to the SSD. /var/log stays in zram.
Somewhat related, I used a generic “hat” (actually a bottom) to connect an SSD to the RPi5 PCIe bus, then used rpi-clone to transfer everything. Now just use the SSD without Zram or SD card
Same here. ZRAM can be removed when using SSDs.
Sorry for dropping the ball on this. I got started back up with school and completely forgot to follow back up on this. My apologies!!
I am also observing intermittent issues with zram syncing after investigation. I’m looking into it, but it seems to be an issue with systemd deciding that it can just keep marching forward with shutdown before completing the full writeback of zram. I’m investigating potential resolutions to the issue, but as with anything more than basic level with systemd, it gets complicated.
If there are any linux savy users here that want to test my changes, they are not final and would need a rebase applied on your end to include the openHAB patches, but if anyone wants to give them a try and provide any feedback, that would be awesome!
Hi,
do you know, when the changes will be released? With the next official OpenHab-release or Openhabian?
Or what is the actual state of the ZRAM-Feature in the openhabian release plan?
I’m not a Linux specialist, but I’m very interested in to get the ZRAM-Sync working properly.
On my Raspi the sync is disabled at the moment.
Best regards
Hi,
Trying to UPDATE zram I get this error from openhabian-config:
2024-12-06_19:59:58_CET [openHABian] Updating zram service...
$ mkdir -p /usr/local/lib/zram-config/
$ rm -f /usr/local/lib/zram-config/overlay
$ systemctl stop zram-config.service
$ install_zram_code /opt/zram
2024-12-06_19:59:59_CET [openHABian] Installing zram code...
$ mkdir -p /opt/zram
$ update_git_repo /opt/zram/zram-config openHAB
2024-12-06_19:59:59_CET [openHABian] Updating zram-config, openHAB branch from git...
$ git -C /opt/zram/zram-config fetch origin
$ git -C /opt/zram/zram-config fetch --tags --force --prune
$ git -C /opt/zram/zram-config reset --hard origin/openHAB
HEAD is now at d3ad15f Add openHAB specific changes
$ git -C /opt/zram/zram-config clean --force -x -d
$ git -C /opt/zram/zram-config checkout openHAB
Already on 'openHAB'
Your branch is up to date with 'origin/openHAB'.
$ git -C /opt/zram/zram-config submodule update --init --recursive
Submodule path 'overlayfs-tools': checked out 'a1e1e33a5359e4cff7d7c60a51620eaa1b315e90'
OK
OK
OK
2024-12-06_20:00:00_CET [openHABian] Updating OverlayFS...
$ meson setup /opt/zram/zram-config/overlayfs-tools/builddir /opt/zram/zram-config/overlayfs-tools
/opt/openhabian/functions/helpers.bash: line 31: meson: command not found**
FAILED (meson setup)
Versions:
openHABian Configuration Tool — [openHAB]{2024-10-25T10:35:12-06:00}(7d97bd8)
openHAB 4.2.3 - Release Build
Is it related to this discussion?
Best regards
I’ve got the same exact error message here. After “uninstall zram” and importing my backup I tried to “Use zram” with the same error.
Pi4, 4GB:
openHABian Configuration Tool — [openHAB]{2024-10-25T10:35:12-06:00}(7d97bd8)
openHAB 4.2.3 - Release BuildOh dear, I’ll look into the install error.
Unsure, probably sometime around Christmas as I’ll be able to finish my testing of the changes around then
@massimiliano.casini @binderth I have pushed changes that hopefully should fix the install/update errors for zram. Please let me know if that did not work.
Hi @ndye,
everything seems ok. Below is the zram upgrade log to check.
openHABian Configuration Tool — [openHAB]{2024-12-09T10:29:33-07:00}(28756be) openHAB 4.2.3 - Release Build
2024-12-10_08:29:41_CET [openHABian] Installing zram required package (meson)...
$ apt-get install --yes -o DPkg::Lock::Timeout= meson
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
ninja-build
The following NEW packages will be installed:
meson ninja-build
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 642 kB of archives.
After this operation, 3,837 kB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian bullseye/main armhf meson all 1.0.0-1.1~bpo11+1~rpt1 [549 kB]
Get:2 http://ftp.arnes.si/mirrors/raspbian/raspbian bullseye/main armhf ninja-build armhf 1.10.1-1 [92.5 kB]
Fetched 642 kB in 1s (841 kB/s)
Selecting previously unselected package ninja-build.
(Reading database ... 81381 files and directories currently installed.)
Preparing to unpack .../ninja-build_1.10.1-1_armhf.deb ...
Unpacking ninja-build (1.10.1-1) ...
Selecting previously unselected package meson.
Preparing to unpack .../meson_1.0.0-1.1~bpo11+1~rpt1_all.deb ...
Unpacking meson (1.0.0-1.1~bpo11+1~rpt1) ...
Setting up ninja-build (1.10.1-1) ...
Setting up meson (1.0.0-1.1~bpo11+1~rpt1) ...
Processing triggers for man-db (2.9.4-2) ...
Updating FireMotD available updates count ...
OK
2024-12-10_08:30:23_CET [openHABian] Updating zram service...
$ systemctl stop zram-config.service
$ mkdir -p /usr/local/lib/zram-config/
$ rm -f /usr/local/lib/zram-config/overlay
$ install_zram_code /opt/zram
2024-12-10_08:30:39_CET [openHABian] Installing zram code...
$ mkdir -p /opt/zram
$ update_git_repo /opt/zram/zram-config openHAB
2024-12-10_08:30:40_CET [openHABian] Updating zram-config, openHAB branch from git...
$ git -C /opt/zram/zram-config fetch origin
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 13 (delta 7), reused 12 (delta 7), pack-reused 0 (from 0)
Unpacking objects: 100% (13/13), 7.44 KiB | 292.00 KiB/s, done.
From https://github.com/ecdye/zram-config
+ d3ad15f...168efb6 openHAB -> origin/openHAB (forced update)
7a0460a..2d2e457 main -> origin/main
+ f5f8f75...9c14a28 sd -> origin/sd (forced update)
$ git -C /opt/zram/zram-config fetch --tags --force --prune
$ git -C /opt/zram/zram-config reset --hard origin/openHAB
HEAD is now at 168efb6 Add openHAB specific changes
$ git -C /opt/zram/zram-config clean --force -x -d
$ git -C /opt/zram/zram-config checkout openHAB
Already on 'openHAB'
Your branch is up to date with 'origin/openHAB'.
$ git -C /opt/zram/zram-config submodule update --init --recursive
Submodule path 'overlayfs-tools': checked out 'a1e1e33a5359e4cff7d7c60a51620eaa1b315e90'
OK
OK
OK
2024-12-10_08:30:43_CET [openHABian] Updating OverlayFS...
$ meson setup /opt/zram/zram-config/overlayfs-tools/builddir /opt/zram/zram-config/overlayfs-tools
The Meson build system
Version: 1.0.0
Source dir: /opt/zram/zram-config/overlayfs-tools
Build dir: /opt/zram/zram-config/overlayfs-tools/builddir
Build type: native build
Project name: overlayfs-tools
Project version: 2024.07
C compiler for the host machine: cc (gcc 10.2.1 "cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110")
C linker for the host machine: cc ld.bfd 2.35.2
Host machine cpu family: arm
Host machine cpu: armv7l
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency musl-fts found: NO (tried pkgconfig)
Library m found: YES
Program test_cases/run_tests.py found: YES (/opt/zram/zram-config/overlayfs-tools/test_cases/run_tests.py)
Build targets in project: 10
Found ninja-1.10.1 at /usr/bin/ninja
$ meson compile -C /opt/zram/zram-config/overlayfs-tools/builddir
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /opt/zram/zram-config/overlayfs-tools/builddir
ninja: Entering directory `/opt/zram/zram-config/overlayfs-tools/builddir'
[6/13] Compiling C object fsck.overlay.p/fsck.c.o
In file included from ../fsck.c:42:
../fsck.c: In function ‘ovl_open_dirs’:
../common.h:32:15: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘rlim_t’ {aka ‘long long unsigned int’} [-Wformat=]
32 | #define _(x) (x)
| ^~~
../fsck.c:71:14: note: in expansion of macro ‘_’
71 | print_info(_("Process fd number limit=%lu "
| ^
../common.h:32:15: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘rlim_t’ {aka ‘long long unsigned int’} [-Wformat=]
32 | #define _(x) (x)
| ^~~
../fsck.c:71:14: note: in expansion of macro ‘_’
71 | print_info(_("Process fd number limit=%lu "
| ^
[13/13] Linking target fsck.overlay
$ meson install -C /opt/zram/zram-config/overlayfs-tools/builddir
ninja: Entering directory `/opt/zram/zram-config/overlayfs-tools/builddir'
ninja: no work to do.
Installing overlay to /usr/local/bin
Installing fsck.overlay to /usr/local/bin
OK
2024-12-10_08:31:02_CET [openHABian] Updating zram logging files...
$ mkdir -p /usr/local/share/zram-config/log
$ install -m 644 /opt/zram/zram-config/service/zram-config.logrotate /etc/logrotate.d/zram-config
$ systemctl -q daemon-reload
$ systemctl restart zram-config.service
OK
Grazie, Ciao