just Iâm not sure why, but I lost the information in the rrd4j-persistence of roughly 2,5 days while installing:
thereâs no more information since Sunday night until now.
I was afraid of that. I still havenât formally pushed the changes that will resolve the occasional issues with data loss when using zram. Hopefully in the next week or two it will be ready to go.
The changes have officially been published, I would welcome testing of them.
If you simply run sudo openhabian-config and allow the tool to update, if you have zram-config installed still it will auto update it just this first time to fix the issues with sync on shutdown/reboot.
If you give it a shot, let me know if you have any questions or observe any issues.
not sure, what you mean by that!
I fired up openhabian-config and openhabian did update itself. How can i test your changes? de-activate ZRAM and re-activate it again? do a reboot�
I fired up openhabian-config and openhabian did update itselfâŠ
After I update zram and this is log. Are ânormalâ the warnig messages during the compilation?
2024-12-18_08:28:34_CET [openHABian] Updating Linux package information... OK
2024-12-18_08:28:34_CET [openHABian] Updating zram service...
$ systemctl stop zram-config.service
$ mkdir -p /usr/local/lib/zram-config/
$ install_zram_code /opt/zram
2024-12-18_08:28:51_CET [openHABian] Installing zram code...
$ mkdir -p /opt/zram
$ update_git_repo /opt/zram/zram-config openHAB
2024-12-18_08:28:52_CET [openHABian] Updating zram-config, openHAB branch from git...
$ git -C /opt/zram/zram-config fetch origin
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 19 (delta 11), reused 15 (delta 8), pack-reused 0 (from 0)
Unpacking objects: 100% (19/19), 8.49 KiB | 107.00 KiB/s, done.
From https://github.com/ecdye/zram-config
+ 168efb6...23a4fe8 openHAB -> origin/openHAB (forced update)
2d2e457..0b83593 main -> origin/main
+ 9c14a28...2293996 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 23a4fe8 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
$ install -m 755 /opt/zram/zram-config/zram-config /usr/local/sbin
$ install -m 644 /opt/zram/zram-config/service/SystemD/zram-config.service /etc/systemd/system/zram-config.service
$ install -m 755 /opt/openhabian/includes/zram-sync /usr/local/sbin
$ install -m 644 /opt/openhabian/includes/SD/zsync.service /opt/openhabian/includes/SD/zsync.timer /etc/systemd/system/
OK
2024-12-18_08:28:58_CET [openHABian] Updating OverlayFS...
$ rm -f /usr/local/lib/zram-config/overlay
$ 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'
[5/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-18_08:29:18_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
openhabian@cm3home:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 6.6G 22G 24% /
devtmpfs 454M 0 454M 0% /dev
tmpfs 486M 0 486M 0% /dev/shm
tmpfs 195M 1.9M 193M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/mmcblk0p1 255M 52M 204M 21% /boot
/dev/zram1 347M 188M 134M 59% /opt/zram/zram1
/dev/zram2 672M 153M 471M 25% /opt/zram/zram2
tmpfs 98M 0 98M 0% /run/user/1000
/dev/zram3 347M 36K 321M 1% /opt/zram/zram3
overlay3 347M 36K 321M 1% /var/lib/openhab/persistence
/dev/zram4 672M 72M 552M 12% /opt/zram/zram4
overlay4 672M 72M 552M 12% /var/log
Hi Ethan,
I recently updated my zram-installation with uninstall and reinstall over openhabian-config. It works fine.
My question is, when will the sync function work properly with openhab.service?
When I use the command /usr/local/sbin/zram-config âsyncâ to manually sync to sd-card, the openhab.service is restarting too.
I would prefer to sync the changes to sd-card at night ones a day without any service restarts. Only syncing from zram-device to sd-card.
Is it actually possible, maybe with a systemd-timer (zsync.service, zsync.timer)?
Thanks, that seems like a better work-around than restarting the service. Is this zram configuration using log:set rather than systemctl restart openhab part of openHABian, or has to be adjusted manually?
Hello again,
if I use the sync-timer in systemd, it doesnât matter. Itâs the same like manually run the command /usr/local/sbin/zram-config âsyncâ.
Manually and with the systemd-timer my openhab, influxdb an grafana-service restarts on every zram-sync.
A Zram sync means to un- and remount so this is to be expected.
You shouldnât be running InfluxDB off zram anyway thatâs not supported. Dangerous, too.
Is this zram configuration using 