Zram not working accordingly on raspberry pi 5

[Lionello_Marrelli]

The same applies on a raspberry pi v3. I also started from the openhabian image 1.9.1
Both persistence and logs are lost after a reboot.
Actually, they are lost even after stopping the zram-config.service.

[Ltty (Florian)]

Hi @ndye,

• Updated zram config via openhabian-config
• Created a file in var/log
• Pulled the zram log file: zram-config.log (36.3 KB)
• Rebooted the system via sudo reboot
• Checked previously created file in var/log which is gone
• Pulled the zram log file: zram-config.log (49.2 KB)

Also, where is the zram config file stored? I wanted to make sure that the config update worked, but the working directory listed in the zram-config.service is empty.

And a random question. Could it be that the problem is 64 bit related? I don’t see this problem on my 32 bit Pi.

@ehorvat1, the behavior in step 10 is expected. If you stop zram and create a file, the file is persisted on your SD card and not in memory. If zram is running, the file only exists in memory. After stopping zram, the file should be moved from memory to your SD card, which for some reason is currently buggy.

[ndye (Ethan Dye)]

@Ltty

And a random question. Could it be that the problem is 64 bit related? I don’t see this problem on my 32 bit Pi.

It is very possible, although looking at the log, it still appears to be due to an upstream change but that should have been resolved by updating. Let me dig into this some more

Also the config file for zram is located at /etc/ztab.

[ndye (Ethan Dye)]

@Ltty @ehorvat1 I have a theory as to why it might be failing, let me explain and then have you test.

I believe that the issue is stemming from the old overlay binary that the system is still picking up even though it shouldn’t. What happens if you run sudo rm -rf /usr/local/lib/zram-config and then try rebooting the system? Does it still give the error in the log where it doesn’t recognize the option to --ignore-mounted?

Also, can you send me the output of running overlay --help.

Hopefully this is the issue, because if so its a fairly easy fix for everyone on our end.

[Ltty (Florian)]

@ndye

I believe that the issue is stemming from the old overlay binary that the system is still picking up even though it shouldn’t. What happens if you run sudo rm -rf /usr/local/lib/zram-config and then try rebooting the system? Does it still give the error in the log where it doesn’t recognize the option to --ignore-mounted?

I can’t find the error anymore. But to be sure, here’s the config after a removing the config and a reboot: zram-config.log (49.2 KB)

@ndye

Also, can you send me the output of running overlay --help.

openhabian@openhabian:~ $ overlay --help
Usage: overlay command options

Commands:
  vacuum - remove duplicated files in upperdir where copy_up is done but the file is not actually modified
  diff   - show the list of actually changed files
  merge  - merge all changes from upperdir to lowerdir, and clear upperdir
  deref  - copy changes from upperdir to a new upperdir unfolding redirect and metacopy

Options:
  -l, --lowerdir=LOWERDIR    the lowerdir of OverlayFS (required)
  -u, --upperdir=UPPERDIR    the upperdir of OverlayFS (required)
  -m, --mountdir=MOUNTDIR    the mountdir of OverlayFS (optional)
  -L, --lowernew=LOWERNEW    the lowerdir of new OverlayFS (optional)
  -U, --uppernew=UPPERNEW    the upperdir of new OverlayFS (optional)
  -i  --ignore-mounted       don't prompt if OverlayFS is still mounted (optional)
  -v, --verbose              with diff action only: when a directory only exists in one version, still list every file of the directory
  -V, --version              print project version
  -b, --brief                with diff action only: conform to output of diff --brief --recursive --no-dereference
  -h, --help                 show this help text

See https://github.com/kmxz/overlayfs-tools/ for warnings and more information.

[ehorvat1]

@Ltty Is command zramctl giving any output after you have issued the sudo rm -rf /usr/local/lib/zram-config ? I am also currently testing and observed that zram does apparentyl not start any more after a removing above mentioned zram-config directory followed by a reboot.
I will do some more testing after I have filled up some carbohydrates for better thinking…

[Lolodomo]

@mstormi

I’m not sure if restoreOnStartup supposed to work at all with rrd4j

Yes, it works but rrd4j does not support items if type String.

[ehorvat1]

@ndye
Tested now the rm -rf /usr/local/lib/zram-config and overlay --help commands:

1. Started with installing zram in openhabian-config (2024-08-21_13:48:43_CEST)
2. Exiting openhabian-config and issued a zramctl gave:

openhabian@openhabian:~ $ zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         1G    4K   87B   12K       4 [SWAP]
/dev/zram1 zstd          750M  508K  6.3K  156K       4 /opt/zram/zram1
/dev/zram2 zstd            1G 16.9M  462K  1.8M       4 /opt/zram/zram2

4. Created a test file in /var/lib/openhab/persistence/rrd4j/
5. After a sudo reboot the file is gone…
6. Issued sudo rm -rf /usr/local/lib/zram-config (Wed Aug 21 01:55:45 PM CEST 2024)
7. zramctl and overlay --help gave this result:

openhabian@openhabian:/var/lib/openhab/persistence/rrd4j $ zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         1G    4K    87B   12K       4 [SWAP]
/dev/zram1 zstd          750M  728K  13.2K  260K       4 /opt/zram/zram1
/dev/zram2 zstd            1G 17.2M 245.7K  1.2M       4 /opt/zram/zram2
openhabian@openhabian:/var/lib/openhab/persistence/rrd4j $ overlay -V
OverlayFS Tools version 2024.07
openhabian@openhabian:/var/lib/openhab/persistence/rrd4j $ overlay --help
Usage: overlay command options

Commands:
  vacuum - remove duplicated files in upperdir where copy_up is done but the file is not actually modified
  diff   - show the list of actually changed files
  merge  - merge all changes from upperdir to lowerdir, and clear upperdir
  deref  - copy changes from upperdir to a new upperdir unfolding redirect and metacopy

Options:
  -l, --lowerdir=LOWERDIR    the lowerdir of OverlayFS (required)
  -u, --upperdir=UPPERDIR    the upperdir of OverlayFS (required)
  -m, --mountdir=MOUNTDIR    the mountdir of OverlayFS (optional)
  -L, --lowernew=LOWERNEW    the lowerdir of new OverlayFS (optional)
  -U, --uppernew=UPPERNEW    the upperdir of new OverlayFS (optional)
  -i  --ignore-mounted       don't prompt if OverlayFS is still mounted (optional)
  -v, --verbose              with diff action only: when a directory only exists in one version, still list every file of the directory
  -V, --version              print project version
  -b, --brief                with diff action only: conform to output of diff --brief --recursive --no-dereference
  -h, --help                 show this help text

See https://github.com/kmxz/overlayfs-tools/ for warnings and more information.

9. Issued sudo reboot and then zramctl gave no output any more … so I seems it failed starting…
10. Attached the zram-config.log file: showing:

zram-config start 2024-08-21-13:48:54-CEST … due to zram install
zram-config stop 2024-08-21-13:53:14-CEST … due to sudo reboot
(overlay: unrecognized option ‘–ignore-mounted’ are still present)
zram-config start 2024-08-21-13:53:31-CEST … system has started…but zram failed see pt. 11 & 12

zram-config.log (12.2 KB)

11. systemctl status zram-config.service gave this:

openhabian@openhabian:/usr/local/share/zram-config/log $ systemctl status zram-config.service
× zram-config.service - zram-config
     Loaded: loaded (/etc/systemd/system/zram-config.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-08-21 14:38:36 CEST; 16s ago
       Docs: https://github.com/ecdye/zram-config/blob/main/README.md
    Process: 2409 ExecStart=/usr/local/sbin/zram-config start (code=exited, status=200/CHDIR)
   Main PID: 2409 (code=exited, status=200/CHDIR)
        CPU: 2ms

Aug 21 14:38:36 openhabian (m-config)[2409]: zram-config.service: Changing to the requested working directory failed: No such file or directory
Aug 21 14:38:36 openhabian (m-config)[2409]: zram-config.service: Failed at step CHDIR spawning /usr/local/sbin/zram-config: No such file or directory
Aug 21 14:38:36 openhabian systemd[1]: Starting zram-config.service - zram-config...
Aug 21 14:38:36 openhabian systemd[1]: zram-config.service: Main process exited, code=exited, status=200/CHDIR
Aug 21 14:38:36 openhabian systemd[1]: zram-config.service: Failed with result 'exit-code'.
Aug 21 14:38:36 openhabian systemd[1]: Failed to start zram-config.service - zram-config.

12. journalctl -xeu zram-config.service gave this result:

Aug 21 14:38:36 openhabian (m-config)[2409]: zram-config.service: Changing to the requested working directory failed: No such file or directory
Aug 21 14:38:36 openhabian (m-config)[2409]: zram-config.service: Failed at step CHDIR spawning /usr/local/sbin/zram-config: No such file or directory
░░ Subject: Process /usr/local/sbin/zram-config could not be executed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The process /usr/local/sbin/zram-config could not be executed and failed.
░░ 
░░ The error number returned by this process is ERRNO.
Aug 21 14:38:36 openhabian systemd[1]: Starting zram-config.service - zram-config...
░░ Subject: A start job for unit zram-config.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit zram-config.service has begun execution.
░░ 
░░ The job identifier is 710.
Aug 21 14:38:36 openhabian systemd[1]: zram-config.service: Main process exited, code=exited, status=200/CHDIR
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ An ExecStart= process belonging to unit zram-config.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 200.
Aug 21 14:38:36 openhabian systemd[1]: zram-config.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit zram-config.service has entered the 'failed' state with result 'exit-code'.
Aug 21 14:38:36 openhabian systemd[1]: Failed to start zram-config.service - zram-config.
░░ Subject: A start job for unit zram-config.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit zram-config.service has finished with a failure.
░░ 
░░ The job identifier is 710 and the job result is failed.

So my conclusion on command: rm -rf /usr/local/lib/zram-config is that zram fails starting after a reboot if /usr/local/lib/zram-config is deleted. Command zramctl does not give any respond.

Reg, Bert

[ehorvat1]

One more:
Looks like stopping zram with command systemctl stop zram-config.service fails which can be seen by checking with zramctl command which will produce still some output. On a working zram the stop process should take som 10,20 seconds, if it is failing the stopping is very quick.

I also tried to update zram-config by running $ sudo /opt/zram/zram-config/update.bash
which produced following output:

openhabian@openhabian:/opt/zram/zram-config $ sudo ./update.bash 
[sudo] password for openhabian: 
branch 'main' set up to track 'origin/main'.
Switched to a new branch 'main'
HEAD is now at 81acd3a Fix code for upstream overlay changes
The Meson build system
Version: 1.0.1
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 12.2.0 "cc (Raspbian 12.2.0-14+rpi1) 12.2.0")
C linker for the host machine: cc ld.bfd 2.40
Host machine cpu family: arm
Host machine cpu: arm
Found pkg-config: /usr/bin/pkg-config (1.8.1)
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.11.1 at /usr/bin/ninja
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'
[4/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:17: 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:28: note: in expansion of macro ‘_’
   71 |                 print_info(_("Process fd number limit=%lu "
      |                            ^
../common.h:32:17: 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:28: note: in expansion of macro ‘_’
   71 |                 print_info(_("Process fd number limit=%lu "
      |                            ^
[13/13] Linking target fsck.overlay
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
Stopping zram-config service
Updating zram-config files
Starting zram-config service
#####        zram-config has been updated         #####
#####     edit /etc/ztab to configure options     #####

NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 zstd          750M  728K  13.7K  240K       4 /opt/zram/zram1
/dev/zram2 zstd            1G  9.5M 216.6K  1.2M       4 /opt/zram/zram2
/dev/zram0 lzo-rle         1G    4K    87B   12K       4 [SWAP]
/dev/zram3 zstd          750M  728K  13.7K  256K       4 /opt/zram/zram3
/dev/zram4 zstd            1G  856K  16.3K  264K       4 /opt/zram/zram4

File /etc/ztab I left untouched and its content is like on a standard Openhabian install.

After this and a reboot I observed no change in zram function … not working.
Reg, Bert

[ndye (Ethan Dye)]

So @Ltty your system appears to be working now?

@ehorvat1 It seems that at some point the zram-config binary got removed from your system, try using openhabian-config to uninstall zram, reboot, then use openhabian-config to reinstall zram and test if it begins working.

[Ltty (Florian)]

Unfortunatly not, @ndye

As @ehorvat1 stated, deleting the zram config via rm -rf /usr/local/lib/zram-config breaks zram.

• After a reboot the output for sudo zramctl is empty
• Re-installing zram via openhabian-config fails with an error during setting up the overlayfs
• Uninstalling and reinstalling works but the zram service fails to start because: Failed at step CHDIR spawning /usr/local/sbin/zram-config: No such file or directory which does not make sense because the directory does exist

I now did a completely fresh install from the Pi Imager (Openhabian 1.9.1). After the installation finished there’s no output for sudo zramctl either. Trying to update/use zram via openhabian-config gives an error.

[Lionello_Marrelli]

@Ltty

Uninstalling and reinstalling works but the zram service fails to start because: Failed at step CHDIR spawning /usr/local/sbin/zram-config: No such file or directory which does not make sense because the directory does exist

I have experienced the same problems with the 32bit openhabian images 1.9.1 (both last and oldstable, i.e. bookworm and bullseye) on my raspberry pi v3b, and with the 32bit openhabian 1.9c version installed in my production raspberry pi v4.
In all three cases the openhabian version was [main]{2024-08-20T21:17:28-06:00}

There are two problems not allowing zram to work, in all three cases:

1. the zram install script do not create the file /usr/local/lib/zram-config
2. the overlay binary does not recognize the “–ignore-mounted” but works with the “-i” option installed (I checked this empirically by issuing the command manually)

I performed a quick and dirty hack by

1. uninstalling zram with openhabian-config
2. deleteting /opt/zram (not sure it is necessary)
3. reinstalling zram withopenhabian-config
   (The install fails due to problem #1 as follows

2024-08-22_15:40:21_CEST [openHABian] Installing zram code...
$ mkdir -p /opt/zram

$ git clone --recurse-submodules --branch openHAB https://github.com/ecdye/zram-config /opt/zram/zram-config
Cloning into '/opt/zram/zram-config'...
remote: Enumerating objects: 1161, done.
remote: Counting objects: 100% (261/261), done.
remote: Compressing objects: 100% (98/98), done.
remote: Total 1161 (delta 227), reused 169 (delta 162), pack-reused 900 (from 1)
Receiving objects: 100% (1161/1161), 555.73 KiB | 1.29 MiB/s, done.
Resolving deltas: 100% (724/724), done.
Submodule 'overlayfs-tools' (https://www.github.com/kmxz/overlayfs-tools) registered for path 'overlayfs-tools'
Cloning into '/opt/zram/zram-config/overlayfs-tools'...
warning: redirecting to https://github.com/kmxz/overlayfs-tools.git/
remote: Enumerating objects: 349, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 349 (delta 36), reused 36 (delta 26), pack-reused 289 (from 1)
Receiving objects: 100% (349/349), 119.78 KiB | 1.58 MiB/s, done.
Resolving deltas: 100% (222/222), done.
Submodule path 'overlayfs-tools': checked out '0b96c2f9226df002d5aa3bc4e8c9e25c73082e3d'
OK
2024-08-22_15:40:25_CEST [openHABian] Setting up OverlayFS...
$ meson setup /opt/zram/zram-config/overlayfs-tools/builddir /opt/zram/zram-config/overlayfs-tools
The Meson build system
Version: 1.0.1
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 12.2.0 "cc (Raspbian 12.2.0-14+rpi1) 12.2.0")
C linker for the host machine: cc ld.bfd 2.40
Host machine cpu family: arm
Host machine cpu: armv7l
Found pkg-config: /usr/bin/pkg-config (1.8.1)
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.11.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:17: 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:28: note: in expansion of macro ‘_’
   71 |                 print_info(_("Process fd number limit=%lu "
      |                            ^
../common.h:32:17: 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:28: 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-08-22_15:40:35_CEST [openHABian] Setting up zram...
$ install -m 755 /opt/zram/zram-config/zram-config /usr/local/sbin

$ install -m 644 /opt/openhabian/includes/ztab /etc/ztab

$ 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/zram-sync /usr/local/sbin

$ install -m 644 /opt/openhabian/includes/SD/zsync.service /opt/openhabian/includes/SD/zsync.timer /etc/systemd/system/

$ mkdir -p /usr/local/share/zram-config/log

$ ln -s /usr/local/share/zram-config/log /var/log/zram-config

$ install -m 644 /opt/zram/zram-config/service/zram-config.logrotate /etc/logrotate.d/zram-config
OK
2024-08-22_15:40:35_CEST [openHABian] Setting up zram service...
$ install -m 644 /opt/zram/zram-config/service/SystemD/zram-config.service /etc/systemd/system/zram-config.service

$ systemctl -q daemon-reload

$ systemctl mask unattended-upgrades.service
Unit unattended-upgrades.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/unattended-upgrades.service → /dev/null.

$ systemctl enable --now zram-config.service
Created symlink /etc/systemd/system/multi-user.target.wants/zram-config.service → /etc/systemd/system/zram-config.service.
Job for zram-config.service failed because the control process exited with error code.
See "systemctl status zram-config.service" and "journalctl -xeu zram-config.service" for details.
FAILED (enable service)

In order to really debug the problem I issued journalctl -xeu zram-config.service -o verbose

4. At this stage disable the service (not sure if it is necessary)

sudo systemctl disable zram-config.service 

5. Create the missing working directory

sudo mkdir /usr/local/lib/zram-config

6. edit directly the service file

sudo nano /usr/local/sbin/zram-config

replace the line

overlay merge --ignore-mounted --lowerdir="${ZDIR}${BIND_DIR}" --upperdir="${ZDIR}${ZRAM_DEV}/upper" &>> "$ZLOG" || return 1

with

overlay merge -i --lowerdir="${ZDIR}${BIND_DIR}" --upperdir="${ZDIR}${ZRAM_DEV}/upper" &>> "$ZLOG" || return 1

7. re-enable the service

sudo systemctl enable  zram-config.service 

8. restart the service

sudo systemctl start  zram-config.service 

After completing this hack, zram is working as expected. Clearly this hack is not going to persist after an update of zram.

[ehorvat1]

Hi, inspired from @Lionello_Marrelli “dirty hack” I also tried this to evaluate the minimal needed changes to have zram working again:

1. Used latest fresh Openhabvian 1.9.1 32 Bit file (on Raspi 4 2GB), after Openhab was setup:
2. sudo openhabian-config … to a) Update System (02) , and b) Update Zram
3. sudo mkdir /usr/local/lib/zram-config (creates missing directory)
4. sudo nano /usr/local/sbin/zram-config … in Line 129: exchange --ignore-mounted with -i
5. sudo reboot
6. created a test file in /var/lib/openhab/persistence/rrd4j followed ba a sudo reboot
7. File remained like it should (Mille grazie Lionello)

So I did not stop zram-config service because it would not stop correctly anyway. Therefore the reboot in step 5.
Now I will test what to do on a Openhabian 1.9.1 based 64Bit system which I was working on and messed up quite a bit regarding zram.

Before restarting a “production” OH system, please do a backup with openhabian-config before. So you have have at least a possibility to restore persistance data. (Better safe than sorry).
Reg, Bert

[ehorvat1]

Forgot one thing:
When starting sudo openhabian-config (Above Pt. 2) then DO NOT press skip on openHABian update available window, choose the defaulted continue option.
Reg, Bert

[ehorvat1]

Repairing zram-config on a Openhabian 1.9.1 64Bit based system was no problem.
Used same procedure as Lionello / in my above post.

Note: Currently the directory /usr/local/lib/zram-config gets deleted when doing a “update zram” in openhabian-config whereas file /usr/local/sbin/zram-config remains unchanged.
If one does a “uninstall zram” followed by a “use zram” the directory is gone and zram-config changes to initial version (so directory has to be added and file has to be edited).

@ndye , could not find valid information about “-i” option for overlay merge (instead --ignore-mounted). But have to admit I did not search too hard … hope you got an idea how to update zram-config (again… ).

But there might be still some issues with zram…but maybe I was the reason by modifying zram-config stuff without stopping zram-config service.
At some point I did see that directory /var/lib/openhab/persistence had wrong file permissions not allowing openhabian user to create files.
So I brutally fixed with: sudo chmod 777 /var/lib/openhab/persistence/ -R and same for log files: sudo chmod 777 /var/log/ -R not sure if zram marked them as read only or so. Made several reboots and persistance data was never lost.

Reg, Bert

[Lionello_Marrelli]

@ehorvat1

At some point I did see that directory /var/lib/openhab/persistence had wrong file permissions not allowing openhabian user to create files.
So I brutally fixed with: sudo chmod 777 /var/lib/openhab/persistence/ -R and same for log files: sudo chmod 777 /var/log/ -R not sure if zram marked them as read only or so.

In principle you can use the openhabian-config option “fix permissions” that correct permissions on all openhab-relevant directories.

[ndye (Ethan Dye)]

OK, sorry for all the issues, I’m not sure what would cause the long style option to work on some systems but not others.

I’ve updated the code in both openhabian and zram-config to reflect the suggestions given here to make it work. If you use openhabian-config (make sure to let it update) and then update zram-config using the menu, let me know if that works. If it doesn’t try uninstalling and reinstalling zram-config and see if that works (it’s possible that the update might not work, but I think it should).

Let me know if that resolves the issue

[Lionello_Marrelli]

Thank you for your quick fix.

I followed your suggestions and it worked:

1. update zram fails, apparently because it does not find the old overlay binary in my system
2. uninstall and reinstall works successfully.

Concerning the problem of the overlay binary not recognizing the long option --ignore-mounted I am wondering why it works on some system.
In fact, by simply looking at the file main.c in the repository https://github.com/kmxz/overlayfs-tools/, it appears that the long option described in the help text ( --ignore-mounted ) is different from the option being processed in the program (which is --ignore).

void print_help(const char *program) {
    printf("Usage: %s command options\n", program);
    puts("");
    puts("Commands:");
    puts("  vacuum - remove duplicated files in upperdir where copy_up is done but the file is not actually modified");
    puts("  diff   - show the list of actually changed files");
    puts("  merge  - merge all changes from upperdir to lowerdir, and clear upperdir");
    puts("  deref  - copy changes from upperdir to a new upperdir unfolding redirect and metacopy");
    puts("");
    puts("Options:");
    puts("  -l, --lowerdir=LOWERDIR    the lowerdir of OverlayFS (required)");
    puts("  -u, --upperdir=UPPERDIR    the upperdir of OverlayFS (required)");
    puts("  -m, --mountdir=MOUNTDIR    the mountdir of OverlayFS (optional)");
    puts("  -L, --lowernew=LOWERNEW    the lowerdir of new OverlayFS (optional)");
    puts("  -U, --uppernew=UPPERNEW    the upperdir of new OverlayFS (optional)");
    puts("  -i  --ignore-mounted       don't prompt if OverlayFS is still mounted (optional)");
    puts("  -v, --verbose              with diff action only: when a directory only exists in one version, still list every file of the directory");
    puts("  -V, --version              print project version");
    puts("  -b, --brief                with diff action only: conform to output of diff --brief --recursive --no-dereference");
    puts("  -h, --help                 show this help text");
    puts("");
    puts("See https://github.com/kmxz/overlayfs-tools/ for warnings and more information.");
}

    static struct option long_options[] = {
        { "lowerdir", required_argument, 0, 'l' },
        { "upperdir", required_argument, 0, 'u' },
        { "mountdir", required_argument, 0, 'm' },
        { "lowernew", required_argument, 0, 'L' },
        { "uppernew", required_argument, 0, 'U' },
        { "ignore",   no_argument      , 0, 'i' },
        { "help",     no_argument      , 0, 'h' },
        { "verbose",  no_argument      , 0, 'v' },
        { "version",  no_argument      , 0, 'V' },
        { "brief",    no_argument      , 0, 'b' },
        { 0,          0,                 0,  0  }
    };

[Ltty (Florian)]

Hi Ethan,

did another clean install and zram works as suspected. I’ll keep an eye on it, but so far, everything looks good again.

What was the issue?

[ehorvat1]

@ndye Can confirm that openhabian-config : use zram / update zram works (tested on Openhabian 1.9.1 64Bit based OH 4.2.1).
Update zram does not delete /usr/local/lib/zram-config any more.

To test if zram is working correctly I do;

1. stop zram-config using: sudo systemctl stop zram-config.service
2. Issue command: zramctl
3. If working ok, then there must not be any output returned. (No output is a good output…)
4. Don’t forget to start again by: sudo systemctl restart zram-config.service
5. Then you can check with zramctl again which should produce some output similar to this:

openhabian@openhabian:/usr/local/sbin $ zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         1G   704K  20,1K  376K       4 [SWAP]
/dev/zram1 zstd          750M 372,7M  30,2M 33,3M       4 /opt/zram/zram1
/dev/zram2 zstd            1G  26,1M 405,3K  1,7M       4 /opt/zram/zram2

(…DISKSIZE is nonstandard in this example):