Upgrading openhab when zram is enabled

[shutterfreak]

There is probably a file permission problem that breaks the openhab upgrade process when zram is enabled. So far I didn't attempt at upgrading openhab before disabling zram so I don't know if it's still a problem.

As workaround, users should first disable zram prior to upgrading openhab.

Ideally, the upgrade script handles this problem. Alternatively, openhabian-config could foresee this.

See a.o. this post

[mstormi]

I can't see from your post what's wrong. Can you please perform your upgrade and if it doesn't work then try openhab-cli reset-ownership. If that still does not work, determine which permissions are still wrong. Eventually that would need to be added to openhab-cli tool but not to openHABian.

[shutterfreak]

I remember to have tried that, and that the upgrade failed.

I also tried to remove the openhab package through apt purge and that bailed out too. Unfortunately I don't have the screen dumps anymore o I'll have to redo the test. I think the main problem is that zram owns /var/lib/openhab when zram is enabled, which interferes with the uninstallation script.

Not sure where this should be addressed, though.

[mstormi]

Hmm, without a "handle" (any command that fails although it shouldn't) I'm afraid I cannot get a grip on that. I was able to upgrade without a problem there. /var/lib/openhab2 won't be removed on uninstall, only if you purge (which you should not do on upgrades).

@BClark09 I had a look at the postrm script and came to think of 2 things: First, this code

removeCache(){
  rm -rf /var/lib/openhab2/cache || true
  rm -rf /var/lib/openhab2/tmp || true
}

is actually removing the dirs, not just their contents as a proper cache cleaning procedure like in openhab-cli does. I vaguely remember that I was hit by this. I think this caused a problem for OH to start because it could not create the dirs again because /var/lib/openhab2 was owned root at that time. I can't explain why - probably is was related to zram "owning" that. I had to run reset-ownership or manually correct ownership to get it to start at that stage. So independent of why that ownership changed, I think it would be a good idea to only remove the contents of the cache dirs so they should remain writable for the openhab user on OH start, wdyt?

Second, on "purge" (but ONLY on purge, not on remove), postrm will remove /var/lib/openhab2. I don't have a well-thought suggestion yet but eventually we could insert a test for zram here and keep it if enabled ? Or omit removal altogether ? (yes that would not be a 100% purge any more then, but hey so what).

[BClark09]

is actually removing the dirs, not just their contents as a proper cache cleaning procedure like in openhab-cli does.

openhab-cli cleans the cache in the same way. This is intentional; the runtime now creates these folders using the user that started the process (openhab using all the usual methods). If /var/lib/openhab2 is owned by a different user than the one that started the process, errors will occur unrelated to the creation of the cache so I am keen to keep this how it is.

Second, on "purge" (but ONLY on purge, not on remove), postrm will remove /var/lib/openhab2. I don't have a well-thought suggestion yet but eventually we could insert a test for zram here and keep it if enabled ?

The openhab apt or yum packages are not aware of other, independant add-ons, and it is a goal for that repo to comply with the apt and YUM spec as possible. This is so that there are no unexpected behaviours. Sorry to say, a purge must purge.

[shutterfreak]

@mstormi I agree that it could be an option to keep the folders and only clear the folder content when clearing the cache.

@BClark09 In case the purge doesn't work, I'd recommend reporting it (instead of bailing out) as some other apt packages do.

[mstormi]

@BClark09 I don't see the point in openhab-cli removing the dirs, why is it that you're "keen on" it ? When doing so manually in the early days before openhab-cli, I only ever removed the contents and never had trouble with that. OH startup will fail if either of these tmp, cache OR the parent /var/lib/openhab2 exists and is not owned by the runtime user, and only tmp/cache are created(createable) by the OH user on starting. The parent is not necessarily writable (excepts on installing the package as root). I (only quickly) glanced at the postinst script and seems it only creates and "chown"s the tmp dir but it does not create, chown or otherwise touch the parent one. Mind you its permissions can change. That possibly happens when mounting/unmounting zram. So shouldn't we chown that as well to the OH user, eventually in openhab-cli but at least in postinst ? If not, why? And what's your suggestion then ?

On purge I see your point (thought you'd raise that :)), I wouldn't want to have dependencies on each other as well.

[mstormi]

after openhab2 stop, /var/lib/openhab2 is owned root:root although I did NOT upgrade or do any changes to ZRAM. Also, this is how it looks after booting. Seems zram mount results in this. That now however I wouldn't know how to change. @BClark09 can we add a chown to the OH startup script ? Should not do harm I think, should it ?

[15:33:47] root@openhabianpi:/var/lib/openhab2# ls -l
insgesamt 56
drwxr-xr-x  2 openhab openhab 4096 Okt 20 13:32 backups
drwxrwxr-x  1 openhab openhab 4096 Dez  1 23:15 config
drwxrwxr-x  1 openhab openhab 4096 Dez  8 15:09 etc
drwxrwxr-x  1 openhab openhab 4096 Dez  8 15:09 jsondb
drwxrwxr-x  1 openhab openhab 4096 Dez  8 15:09 log
drwxrwxr-x+ 2 openhab openhab 4096 Dez  8 15:09 max
drwxrwxr-x  2 openhab openhab 4096 Aug 24 11:52 pax-web-jsp
drwxrwxr-x  1 openhab openhab 4096 Aug 24 11:52 persistence
drwxrwxr-x  2 openhab openhab 4096 Dez  8 15:09 zwave
[15:33:49] root@openhabianpi:/var/lib/openhab2# mkdir tmp cache
[15:33:57] root@openhabianpi:/var/lib/openhab2# chown openhab:openhab tmp cache
[15:34:05] root@openhabianpi:/var/lib/openhab2# ls -lad . tmp cache
drwxr-xr-x 1 root    root    4096 Dez  8 15:33 .
drwxr-xr-x 2 openhab openhab 4096 Dez  8 15:33 cache
drwxr-xr-x 2 openhab openhab 4096 Dez  8 15:33 tmp

[mstormi]

@BClark09 would it be right and where would be the place to add a "chown" to the OH startup script ?

[mstormi]

@shutterfreak please compare your installed openhabian/zram code (/usr/local/bin/zram-config, that should be) to https://github.com/mstormi/openhabian-zram/blob/master/zram-config Does it have the chown and chmod commands at line 52?

Get this version and put it to /usr/local/bin, then try upgrading OH with this in place.

[BClark09]

Sorry for the delay!

I don't see the point in openhab-cli removing the dirs, why is it that you're "keen on" it ?

If I'm honest, for simplicities sake. At the time those scripts were made, it was possible to override the owner and group of the package. So, knowing that the runtime always creates the folder, it was easier to delete the directory than it is to delete all the contents in the directory, or remake the folder and assume the user and group to set it afterwards.

In case the purge doesn't work, I'd recommend reporting it (instead of bailing out) as some other apt packages do.

Agreed!

So shouldn't we chown that as well to the OH user, eventually in openhab-cli but at least in postinst ?

I think so, postinst would be the best place to do this. I can create a PR for after the 2.5 release.

@BClark09 would it be right and where would be the place to add a "chown" to the OH startup script ?

Which startup script? If it's the service file for systemd, you could write a set of ExecStartPre=+/bin/chown commands using the $OPENHAB_USER variable.

[mstormi]

I've merged https://github.com/mstormi/openhabian-zram/pull/2 which should fix ZRAM startup changing permissions, let's see if that works out (unfortunately it applies to new ZRAM setups only). @shutterfreak waiting for your feedback...

[shutterfreak]

@shutterfreak please compare your installed openhabian/zram code (/usr/local/bin/zram-config, that should be) to https://github.com/mstormi/openhabian-zram/blob/master/zram-config Does it have the chown and chmod commands at line 52?

--- /usr/local/bin/zram-config  2019-12-02 09:46:32.717821187 +0100
+++ ./zram-config   2019-12-14 20:03:53.000000000 +0100
@@ -45,8 +45,8 @@
            mke2fs -v -t ${dirFsType} /dev/zram${RAM_DEV} >>${ZLOG} 2>&1 || return 1
            mkdir -p ${ZDIR}/zram${RAM_DEV} >>${ZLOG} 2>&1 || return 1
            mount --verbose --types ${dirFsType} -o ${dirMountOpt} /dev/zram${RAM_DEV} ${ZDIR}/zram${RAM_DEV}/ >>${ZLOG} 2>&1 || return 1
-           chown $dirUser:$dirGroup ${ZDIR}/zram${RAM_DEV} >>${ZLOG} 2>&1 || return 1
-           chmod $dirPerm ${ZDIR}/zram${RAM_DEV} >>${ZLOG} 2>&1 || return 1
+           chown $dirUser:$dirGroup ${ZDIR}/zram${RAM_DEV} ${ZDIR}/zram${RAM_DEV}/upper ${ZDIR}/zram${RAM_DEV}/workdir >>${ZLOG} 2>&1 || return 1
+           chmod $dirPerm ${ZDIR}/zram${RAM_DEV} ${ZDIR}/zram${RAM_DEV}/upper ${ZDIR}/zram${RAM_DEV}/workdir >>${ZLOG} 2>&1 || return 1
            mkdir -p ${ZDIR}/zram${RAM_DEV}/upper ${ZDIR}/zram${RAM_DEV}/workdir ${TARGET_DIR} >>${ZLOG} 2>&1 || return 1
            mount --verbose --types overlay -o redirect_dir=on,lowerdir=${ZDIR}${BIND_DIR},upperdir=${ZDIR}/zram${RAM_DEV}/upper,workdir=${ZDIR}/zram${RAM_DEV}/workdir overlay${RAM_DEV} ${TARGET_DIR} >>${ZLOG} 2>&1 || return 1
            chown $dirUser:$dirGroup ${TARGET_DIR} >>${ZLOG} 2>&1 || return 1

Get this version and put it to /usr/local/bin, then try upgrading OH with this in place.

You want me to replace the current version of zram-config (which came along openhabian-config some time around 2.5 M4 or 2.5 M5 I think) with the linked one?

[mstormi]

You want me to replace the current version of zram-config (which came along openhabian-config some time around 2.5 M4 or 2.5 M5 I think) with the linked one?

yes please

[shutterfreak]

Done.

I'm currently on openHAB 2.5.0.RC1. I'll report when upgrading to the next release.

[mstormi]

Did you restart ZRAM or reboot? Please check ownership and permissions of all those directories the script mounts, in particular after zram stop. Script is now meant to recreate/re-mount those with their current permissions (as it reads them to be on zram start). But if one of them still has old (and wrong) permissions, it'll reset those.

[shutterfreak]

Here's what I see when rebooting with shutdown -r now after the edit above:

[17:26:55] openhabian@openhab:~$ sudo -u root bash
[sudo] password for openhabian: 
[17:27:02] root@openhab:/home/openhabian# cd /var/lib/openhab2/
[17:27:06] root@openhab:/var/lib/openhab2# ls -la .
total 124
drwxr-xr-x 17 openhab openhab  4096 Dec 15 11:32 .
drwxr-xr-x 38 root    root     4096 Dec  9 13:51 ..
drwxr-xr-x  2 root    root     4096 Nov 19 22:00 backups
-rw-------  1 openhab openhab  6725 Dec 14 20:15 .bash_history
drwxr-xr-x  5 openhab openhab  4096 Dec  9 22:03 .cache
drwxr-xr-x  4 openhab openhab  4096 Dec 15 11:30 cache
-rw-r--r--  1 openhab openhab  1172 Nov 18 13:34 Californium.properties
drwx------  3 openhab openhab  4096 Nov 18 13:54 .config
drwxr-xr-x  6 openhab openhab  4096 Dec 15 11:32 config
drwxr-xr-x  3 openhab openhab 12288 Dec 15 11:32 etc
drwxr-xr-x  3 openhab openhab  4096 Nov 19 01:05 .java
drwxr-xr-x  3 openhab openhab  4096 Dec 15 11:32 jsondb
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 .karaf
drwxr-xr-x  3 openhab openhab  4096 Nov 19 21:38 .local
drwxr-xr-x  2 openhab openhab  4096 Nov 18 16:22 openhabcloud
drwxr-xr-x  5 openhab openhab  4096 Nov 18 13:34 persistence
drwx------  2 openhab openhab  4096 Nov 18 21:53 .ssh
drwxr-xr-x  8 openhab openhab  4096 Dec 15 17:27 tmp
-rw-r--r--  1 openhab openhab    36 Nov 18 16:22 uuid
-rw-------  1 openhab openhab 24971 Dec 12 12:02 .viminfo
-rw-r--r--  1 openhab openhab   215 Dec 14 20:03 .wget-hsts
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 zwave
[17:27:19] root@openhab:/var/lib/openhab2# 

And for the record, here's the non-comment content of /etc/ztab:

# swap  alg mem_limit   disk_size   swap_priority   page-cluster    swappiness
swap    lz4 200M        600M        75      0       90

# dir   alg mem_limit   disk_size   target_dir      bind_dir
dir lz4 200M        600M        /var/lib/openhab2   /openhab2.bind

# log   alg mem_limit   disk_size   target_dir      bind_dioldlog_dir
log lzo 150M        500M        /var/log        /log.bind

[mstormi]

is that after zram-config stop ? Did you verifiy there's no mounts left ? (df, zramctl) Asking because it looks fine to me and wouldn't explain your problem (unless you chown'ed manually).

[mstormi]

Please download https://github.com/mstormi/openhabian-zram/blob/master/zram-config again before upgrading.

[shutterfreak]

It was while openHAB and zram were active.

Here's what happens when stopping openHAB and then stopping ZRAM:

[09:36:21] openhabian@openhab:~$ sudo -u root bash
[sudo] password for openhabian: 
[09:36:28] root@openhab:/home/openhabian# cd /var/lib/openhab2/
[09:36:32] root@openhab:/var/lib/openhab2# ls -la
total 124
drwxr-xr-x 17 openhab openhab  4096 Dec 15 11:32 .
drwxr-xr-x 38 root    root     4096 Dec  9 13:51 ..
drwxr-xr-x  2 root    root     4096 Nov 19 22:00 backups
-rw-------  1 openhab openhab  6725 Dec 14 20:15 .bash_history
drwxr-xr-x  5 openhab openhab  4096 Dec  9 22:03 .cache
drwxr-xr-x  4 openhab openhab  4096 Dec 15 11:30 cache
-rw-r--r--  1 openhab openhab  1172 Nov 18 13:34 Californium.properties
drwx------  3 openhab openhab  4096 Nov 18 13:54 .config
drwxr-xr-x  6 openhab openhab  4096 Dec 15 11:32 config
drwxr-xr-x  3 openhab openhab 12288 Dec 15 11:32 etc
drwxr-xr-x  3 openhab openhab  4096 Nov 19 01:05 .java
drwxr-xr-x  3 openhab openhab  4096 Dec 15 11:32 jsondb
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 .karaf
drwxr-xr-x  3 openhab openhab  4096 Nov 19 21:38 .local
drwxr-xr-x  2 openhab openhab  4096 Nov 18 16:22 openhabcloud
drwxr-xr-x  5 openhab openhab  4096 Nov 18 13:34 persistence
drwx------  2 openhab openhab  4096 Nov 18 21:53 .ssh
drwxr-xr-x  9 openhab openhab  4096 Dec 15 21:26 tmp
-rw-r--r--  1 openhab openhab    36 Nov 18 16:22 uuid
-rw-------  1 openhab openhab 24971 Dec 12 12:02 .viminfo
-rw-r--r--  1 openhab openhab   215 Dec 14 20:03 .wget-hsts
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 zwave

[09:36:46] root@openhab:/var/lib/openhab2# ls -la /var/log/openhab2/
total 2584
drwxr-xr-x  3 openhab openhab    4096 Dec 16 00:00 .
drwxr-xr-x 14 root    root       4096 Dec 16 00:00 ..
drwxr-xr-x  3 openhab openhab    4096 Dec  2 09:44 archive
-rw-r--r--  1 openhab openhab       0 Nov 18 13:46 audit.log
-rw-r--r--  1 openhab openhab 1285209 Dec 16 09:36 events.log
-rw-r--r--  1 openhab openhab 1338296 Dec 16 09:35 openhab.log
-rwxr-xr-x  1 openhab openhab       0 Dec  9 23:48 Readme.txt
[09:36:49] root@openhab:/var/lib/openhab2# systemctl stop openhab2
Warning: The unit file, source configuration file or drop-ins of openhab2.service changed on disk. Run 'systemctl daemon-reload' to reload units.

[09:37:27] root@openhab:/var/lib/openhab2# systemctl daemon-reload

[09:37:38] root@openhab:/var/lib/openhab2# ls -la
total 124
drwxr-xr-x 17 openhab openhab  4096 Dec 15 11:32 .
drwxr-xr-x 38 root    root     4096 Dec  9 13:51 ..
drwxr-xr-x  2 root    root     4096 Nov 19 22:00 backups
-rw-------  1 openhab openhab  6725 Dec 14 20:15 .bash_history
drwxr-xr-x  5 openhab openhab  4096 Dec  9 22:03 .cache
drwxr-xr-x  4 openhab openhab  4096 Dec 16 09:37 cache
-rw-r--r--  1 openhab openhab  1172 Nov 18 13:34 Californium.properties
drwx------  3 openhab openhab  4096 Nov 18 13:54 .config
drwxr-xr-x  6 openhab openhab  4096 Dec 15 11:32 config
drwxr-xr-x  3 openhab openhab 12288 Dec 15 11:32 etc
drwxr-xr-x  3 openhab openhab  4096 Nov 19 01:05 .java
drwxr-xr-x  3 openhab openhab  4096 Dec 15 11:32 jsondb
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 .karaf
drwxr-xr-x  3 openhab openhab  4096 Nov 19 21:38 .local
drwxr-xr-x  2 openhab openhab  4096 Nov 18 16:22 openhabcloud
drwxr-xr-x  5 openhab openhab  4096 Nov 18 13:34 persistence
drwx------  2 openhab openhab  4096 Nov 18 21:53 .ssh
drwxr-xr-x  7 openhab openhab  4096 Dec 16 09:37 tmp
-rw-r--r--  1 openhab openhab    36 Nov 18 16:22 uuid
-rw-------  1 openhab openhab 24971 Dec 12 12:02 .viminfo
-rw-r--r--  1 openhab openhab   215 Dec 14 20:03 .wget-hsts
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 zwave

[09:37:46] root@openhab:/var/lib/openhab2# ls -la backups/
total 8
drwxr-xr-x  2 root    root    4096 Nov 19 22:00 .
drwxr-xr-x 17 openhab openhab 4096 Dec 15 11:32 ..

[09:38:07] root@openhab:/var/lib/openhab2# systemctl stop zram-config 

[09:38:32] root@openhab:/var/lib/openhab2# ls -la
total 124
drwxr-xr-x 17 openhab openhab  4096 Dec 15 11:32 .
drwxr-xr-x 38 root    root     4096 Dec  9 13:51 ..
drwxr-xr-x  2 root    root     4096 Nov 19 22:00 backups
-rw-------  1 openhab openhab  6725 Dec 14 20:15 .bash_history
drwxr-xr-x  5 openhab openhab  4096 Dec  9 22:03 .cache
drwxr-xr-x  4 openhab openhab  4096 Dec 16 09:37 cache
-rw-r--r--  1 openhab openhab  1172 Nov 18 13:34 Californium.properties
drwx------  3 openhab openhab  4096 Nov 18 13:54 .config
drwxr-xr-x  6 openhab openhab  4096 Dec 15 11:32 config
drwxr-xr-x  3 openhab openhab 12288 Dec 15 11:32 etc
drwxr-xr-x  3 openhab openhab  4096 Nov 19 01:05 .java
drwxr-xr-x  3 openhab openhab  4096 Dec 15 11:32 jsondb
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 .karaf
drwxr-xr-x  3 openhab openhab  4096 Nov 19 21:38 .local
drwxr-xr-x  2 openhab openhab  4096 Nov 18 16:22 openhabcloud
drwxr-xr-x  5 openhab openhab  4096 Nov 18 13:34 persistence
drwx------  2 openhab openhab  4096 Nov 18 21:53 .ssh
drwxr-xr-x  7 openhab openhab  4096 Dec 16 09:37 tmp
-rw-r--r--  1 openhab openhab    36 Nov 18 16:22 uuid
-rw-------  1 openhab openhab 24971 Dec 12 12:02 .viminfo
-rw-r--r--  1 openhab openhab   215 Dec 14 20:03 .wget-hsts
drwxr-xr-x  2 openhab openhab  4096 Dec 15 11:32 zwave

[09:40:42] root@openhab:/var/lib/openhab2# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=494908k,nr_inodes=123727,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p2 on /srv/openhab2-logs type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-conf type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-sys type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-userdata type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-addons type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mmcblk0p2 on /opt/zram/openhab2.bind type ext4 (rw,noatime)
/dev/zram1 on /opt/zram/zram1 type ext4 (rw,noatime)
/dev/mmcblk0p2 on /opt/zram/log.bind type ext4 (rw,noatime)
/dev/zram2 on /opt/zram/zram2 type ext4 (rw,noatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=99900k,mode=700,uid=1000,gid=1000)

[09:40:47] root@openhab:/var/lib/openhab2# 

So it appears that some zram mount points still exist after stopping the zram-config service.

Do you want me to upgrade openHAB while zram is active or inactive?

[shutterfreak]

Meanwhile I downloaded your new version of zram-config to /usr/local/bin/ and did a precautionary systemctl daemon-reload.

[mstormi]

So it appears that some zram mount points still exist after stopping the zram-config service.

Mmh. That now would be some other problem. See zlog (/usr/local/share/zram-config/log/zram-config.log) lines to contain "remove" to see if that gets you a hint why it didn't work. (then again it's quite possible, there was a bug to show that behavior, and I don't know how old your script was i.e. if it contained the fix already) Next time, eventually add a "-x" to the first line of zram-config so we'll get to see every command and its output right away.

Do you want me to upgrade openHAB while zram is active or inactive?

Inactive, please - the problem was that /var/lib/openhab2 was not owned by openhab on OH start because ZRAM mount causes that to become owned root. Now it'll obviously be correct if you just stop OH (else that wouldn't have run). So stop & start again ZRAM after stopping OH, then upgrade and start OH (eventually the upgrade procedure includes starting, too. Try to get another look at ownership/permissions by that time.

[shutterfreak]

Here we go again.

[11:55:52] root@openhab:/home/openhabian# tail -f /usr/local/share/zram-config/log/zram-config.log &
[1] 14547

ztab create log lzo 150M 500M /var/log /log.bind   
Warning: Stopping rsyslog.service, but it can still be activated by:
  syslog.socket
dirPerm /var/log 755 0:0
mount: /var/log bound on /opt/zram/log.bind.
mount: /opt/zram/log.bind propagation flags changed.
dirMountOpt rw,noatime rw,noatime dirFsType  ext4 ext4
zram4 created comp_algorithm=lzo mem_limit=150M disksize=500M
mke2fs 1.44.5 (15-Dec-2018)
mke2fs: invalid blocks '/dev/zram4' on device 'ext4'

[11:56:10] root@openhab:/home/openhabian# systemctl stop openhab2

[11:56:44] root@openhab:/home/openhabian# systemctl stop zram-config 
zram-config stop 2019-12-16-11:57:11
tail: /usr/local/share/zram-config/log/zram-config.log: file truncated
ztab remove swap /zram0 zram-config0 
/dev/zram0 removed
removed '/usr/local/share/zram-config/zram-device-list.rev'
removed '/usr/local/share/zram-config/zram-device-list'

[11:57:12] root@openhab:/home/openhabian# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=494908k,nr_inodes=123727,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p2 on /srv/openhab2-logs type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-conf type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-sys type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-userdata type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-addons type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mmcblk0p2 on /opt/zram/openhab2.bind type ext4 (rw,noatime)
/dev/zram1 on /opt/zram/zram1 type ext4 (rw,noatime)
/dev/mmcblk0p2 on /opt/zram/log.bind type ext4 (rw,noatime)
/dev/zram2 on /opt/zram/zram2 type ext4 (rw,noatime)
/dev/mmcblk0p2 on /opt/zram/openhab2.bind type ext4 (rw,noatime)
/dev/mmcblk0p2 on /opt/zram/log.bind type ext4 (rw,noatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=99900k,mode=700,uid=1000,gid=1000)

[11:57:53] root@openhab:/home/openhabian# cat /usr/local/share/zram-config/log/zram-config.log
ztab remove swap /zram0 zram-config0 
/dev/zram0 removed
removed '/usr/local/share/zram-config/zram-device-list.rev'
removed '/usr/local/share/zram-config/zram-device-list'

[11:58:02] root@openhab:/home/openhabian# tail -f /usr/local/share/zram-config/log/zram-config.log &
[1] 14549
[11:58:29] root@openhab:/home/openhabian# 
ztab remove swap /zram0 zram-config0 
/dev/zram0 removed
removed '/usr/local/share/zram-config/zram-device-list.rev'
removed '/usr/local/share/zram-config/zram-device-list'

[11:58:32] root@openhab:/home/openhabian# systemctl start zram-config 
zram-config start 2019-12-16-11:58:40
ztab create swap lz4 200M 600M 75 0 90  
zram0 created comp_algorithm=lz4 mem_limit=200M disksize=600M
Setting up swapspace version 1, size = 600 MiB (629141504 bytes)
LABEL=zram-config0, UUID=32b32898-999d-4449-b981-e5b2d144dcfd
swapon: /dev/zram0: found signature [pagesize=4096, signature=swap]
swapon: /dev/zram0: pagesize=4096, swapsize=629145600, devsize=629145600
swapon /dev/zram0
vm.page-cluster = 0
vm.swappiness = 90
ztab create dir lz4 200M 600M /var/lib/openhab2 /openhab2.bind   
dirPerm /var/lib/openhab2 755 110:115
mount: /var/lib/openhab2 bound on /opt/zram/openhab2.bind.
mount: /opt/zram/openhab2.bind propagation flags changed.
dirMountOpt rw,noatime rw,noatime rw,noatime dirFsType  ext4 ext4 ext4
zram5 created comp_algorithm=lz4 mem_limit=200M disksize=600M
mke2fs 1.44.5 (15-Dec-2018)
mke2fs: invalid blocks 'ext4' on device 'ext4'
ztab create log lzo 150M 500M /var/log /log.bind   
Warning: Stopping rsyslog.service, but it can still be activated by:
  syslog.socket
dirPerm /var/log 755 0:0
mount: /var/log bound on /opt/zram/log.bind.
mount: /opt/zram/log.bind propagation flags changed.
dirMountOpt rw,noatime rw,noatime rw,noatime dirFsType  ext4 ext4 ext4
zram6 created comp_algorithm=lzo mem_limit=150M disksize=500M
mke2fs 1.44.5 (15-Dec-2018)
mke2fs: invalid blocks 'ext4' on device 'ext4'

[11:58:40] root@openhab:/home/openhabian# 

So it appears that there's indeed something wrong. Unsure if it's the SD card that's failing or if there's some other obscure problem at work.

I'll now do as you described: stop OH, stop-start zram, upgrade, start OH.

[mstormi]

Unsure if it's the SD card that's failing or if there's some other obscure problem at work. You mean the 'invalid blocks' on ext4 ? Yeah, not sure of that either. I had seen it at times, too, but I wouldn't think it's zram related.

What zram devices do you see now when running ? I suspect you have four of them (old two, new two, plus 1x swap). Did you reboot recently ? That makes zram-config start from 0(1) again.

What do /usr/local/share/zram-config/zram-device-list (and .rev) look like ?

[shutterfreak]

Here's the log of upgrading openHAB2 while it is not running (zram is running):

[12:05:35] root@openhab:/home/openhabian# apt upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  openhab2
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 82.6 MB of archives.
After this operation, 8,192 B disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 https://openhab.jfrog.io/openhab/openhab-linuxpkg testing/main armhf openhab2 all 2.5.0-1 [82.6 MB]
Fetched 82.6 MB in 13s (6,323 kB/s)                                                                                                             
Reading changelogs... Done
(Reading database ... 72957 files and directories currently installed.)
Preparing to unpack .../openhab2_2.5.0-1_all.deb ...
Unpacking openhab2 (2.5.0-1) over (2.5.0~RC1-1) ...
Setting up openhab2 (2.5.0-1) ...

[openHAB] Performing post-update tasks for version 2.5.0:
  Replacing: String org.eclipse.smarthome.core.i18nprovider to org.eclipse.smarthome.i18n in file /var/lib/openhab2/config/org/eclipse/smarthome/i18n.config

[openHAB] Listing important changes for version 2.5.0:
  Warning:  Azure IoT: Due to changes in the Azure API, this add-on is no longer working and has been removed.
  Warning:  DarkSky Binding: The item type of 'rain' and 'snow' channels have been changed to 'Number:Speed'.
  Warning:  EnOcean Binding: Channel 'receivingState' has been removed, because this was a string containing many information. For this, there are three new channels: 'rssi', 'repeatCount' and 'lastReceived'.
  Warning:  Homekit: Some tags have been renamed. Old names will not be supported in future versions. Please check documentation.
  Warning:  LGWebOS Binding: The binding parameter 'localIP' has been removed. The binding now uses system defaults for network communication. The thing type parameter 'deviceId' is no longer a parameter, but a property. Parameters 'host' and 'key' have been added.
  Warning:  Mail Action: The mail action has been replaced by a new mail binding.
  Warning:  MQTT Binding: Homie channel names may have changed if special characters are used for MQTT topic names.
  Warning:  OneWire Binding: Some thing types have changed and need to be updated in textual configurations. See documentation for further information.
  Warning:  OpenSprinkler Binding: The stationXX channels have been removed and replaced by a bridge/thing combination. See documentation for further information.
  Warning:  OpenSprinkler Binding: The Pi interface was removed, as it does not provide all of the features of the binding anymore. Please use the HTTP interface instead.
  Warning:  Pushbullet Action: The pushbullet action has been replaced by a new pushbullet binding.
  Warning:  REST Docs: This add-on is now part of the UIs. When previously installed using a UI, uninstall the REST Docs before updating and reinstall it after the update to prevent errors. When installing it using textual configuration, update 'services/addons.cfg' by removing 'restdocs' from 'misc' and add it to 'ui' instead.
  Warning:  senseBox Binding: The senseBox binding is now using Units of Measurements, and the channel name for Illuminance has changed. The Items must be reconfigured.
  Warning:  Somfytahoma Binding: The following channels have been renamed: 'cyclic_button_state' to 'cyclic_button', 'battery_status_state' to 'battery_status' and 'lighting_led_pod_mod_state' to 'lighting_led_pod_mode'.
  Warning:  Systeminfo Binding: The 'cpu#load' channel has been removed because the OSHI library no longer provides this information.
  Warning:  TP-Link Smart Home Binding: The energy and rssi channels are now using Units of Measurements. Items must be adapted and the things must be recreated.
  Warning:  Tesla Binding: The binding has been heavily refactored. It is required to delete old Tesla Things and set them up from scratch.
  Warning:  Vitotronic Binding: The following channels have been renamed: 'outsite_temp' to 'outside_temp', 'pelletburner:power' to 'pelletburner:powerlevel', 'party_temp' to 'party_temp_setpoint' and 'save_temp' to 'save_temp_setpoint'

[openHAB] openHAB was not running so will not start after upgrade.
[openHAB] Please use the command:
            sudo /bin/systemctl start openhab2.service

Processing triggers for systemd (241-7~deb10u2+rpi1) ...
Updating FireMotD available updates count ... 
[12:06:48] root@openhab:/home/openhabian# systemctl start openhab2
[12:26:19] root@openhab:/home/openhabian# 

So the upgrade gave no problems.

What zram devices do you see now when running ? I suspect you have four of them (old two, new two, plus 1x swap). Did you reboot recently ? That makes zram-config start from 0(1) again.

[12:27:18] root@openhab:/home/openhabian# ls -l /dev/zram*
brw-rw---- 1 root disk 254, 0 Dec 16 11:58 /dev/zram0
brw-rw---- 1 root disk 254, 1 Dec 15 17:26 /dev/zram1
brw-rw---- 1 root disk 254, 2 Dec 15 17:26 /dev/zram2
brw-rw---- 1 root disk 254, 3 Dec 16 09:46 /dev/zram3
brw-rw---- 1 root disk 254, 4 Dec 16 09:46 /dev/zram4
brw-rw---- 1 root disk 254, 5 Dec 16 11:58 /dev/zram5
brw-rw---- 1 root disk 254, 6 Dec 16 11:58 /dev/zram6

[12:27:36] root@openhab:/home/openhabian# uptime
 12:28:28 up 19:01,  1 user,  load average: 1.20, 0.84, 0.43

There are 7 zram devices.

I rebooted yesterday, and will reboot later today once OSGi did most of its magic.

What do /usr/local/share/zram-config/zram-device-list (and .rev) look like ?

cat /usr/local/share/zram-config/zram-device-list
swap        /zram0      zram-config0

[12:28:28] root@openhab:/home/openhabian# ls -l /usr/local/share/zram-config/ total 20 drwxr-xr-x 2 root root 4096 Dec 2 09:46 log -rw-r--r-- 1 root root 4917 Dec 2 09:46 ro-root.sh -rw-r--r-- 1 root root 462 Dec 2 09:46 uninstall.sh -rw-r--r-- 1 root root 27 Dec 16 11:58 zram-device-list

[mstormi]

ok, the upgrade worked - good. Eventually remove /usr/local/share/zram-config/zram-device-list* before rebooting. That should get you back to 3 devices (1 swap of those) as defined in ztab, with the updated zram-config let's hope you remain there even when stop/starting ZRAM. Thanks for testing.

[shutterfreak]

Here's the status after rebooting:

[12:46:29] openhabian@openhab:~$ sudo -u root bash
[12:46:35] root@openhab:/home/openhabian# ls -l /dev/zram*
brw-rw---- 1 root disk 254, 0 Dec 16 12:34 /dev/zram0
brw-rw---- 1 root disk 254, 1 Dec 16 12:34 /dev/zram1
brw-rw---- 1 root disk 254, 2 Dec 16 12:34 /dev/zram2

[12:47:04] root@openhab:/home/openhabian# cat /usr/local/share/zram-config/zram-device-list
swap        /zram0      zram-config0
dir     /zram1      /var/lib/openhab2       /openhab2.bind
log     /zram2      /var/log        /log.bind

[12:47:17] root@openhab:/home/openhabian# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=494908k,nr_inodes=123727,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p2 on /srv/openhab2-addons type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-userdata type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-conf type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-logs type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-sys type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mmcblk0p2 on /opt/zram/openhab2.bind type ext4 (rw,noatime)
/dev/zram1 on /opt/zram/zram1 type ext4 (rw,noatime)
overlay1 on /var/lib/openhab2 type overlay (rw,relatime,lowerdir=/opt/zram/openhab2.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
overlay1 on /srv/openhab2-userdata type overlay (rw,relatime,lowerdir=/opt/zram/openhab2.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
/dev/mmcblk0p2 on /opt/zram/log.bind type ext4 (rw,noatime)
/dev/zram2 on /opt/zram/zram2 type ext4 (rw,noatime)
overlay2 on /var/log type overlay (rw,relatime,lowerdir=/opt/zram/log.bind,upperdir=/opt/zram/zram2/upper,workdir=/opt/zram/zram2/workdir,redirect_dir=on)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=99900k,mode=700,uid=1000,gid=1000)

[12:47:28] root@openhab:/home/openhabian# cat /usr/local/share/zram-config/log/zram-config.log
ztab remove swap /zram0 zram-config0 
/dev/zram0 removed
removed '/usr/local/share/zram-config/zram-device-list.rev'
removed '/usr/local/share/zram-config/zram-device-list'
zram-config start 2019-12-16-12:34:06
ztab create swap lz4 200M 600M 75 0 90  
insmod /lib/modules/4.19.75-v7+/kernel/mm/zsmalloc.ko 
insmod /lib/modules/4.19.75-v7+/kernel/drivers/block/zram/zram.ko 
zram0 created comp_algorithm=lz4 mem_limit=200M disksize=600M
Setting up swapspace version 1, size = 600 MiB (629141504 bytes)
LABEL=zram-config0, UUID=70f96eaa-a8f4-44ad-ac2f-645532000b68
swapon: /dev/zram0: found signature [pagesize=4096, signature=swap]
swapon: /dev/zram0: pagesize=4096, swapsize=629145600, devsize=629145600
swapon /dev/zram0
vm.page-cluster = 0
vm.swappiness = 90
ztab create dir lz4 200M 600M /var/lib/openhab2 /openhab2.bind   
dirPerm /var/lib/openhab2 755 110:115
mount: /var/lib/openhab2 bound on /opt/zram/openhab2.bind.
mount: /opt/zram/openhab2.bind propagation flags changed.
dirMountOpt rw,noatime dirFsType  ext4
zram1 created comp_algorithm=lz4 mem_limit=200M disksize=600M
mke2fs 1.44.5 (15-Dec-2018)
fs_types for mke2fs.conf resolution: 'ext4'
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
38400 inodes, 153600 blocks
7680 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=157286400
5 block groups
32768 blocks per group, 32768 fragments per group
7680 inodes per group
Filesystem UUID: f93c1885-8c63-48d4-a588-408ad3feaf96
Superblock backups stored on blocks: 
    32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

mount: /dev/zram1 mounted on /opt/zram/zram1.
mount: overlay1 mounted on /var/lib/openhab2.
ztab create log lzo 150M 500M /var/log /log.bind   
Warning: Stopping rsyslog.service, but it can still be activated by:
  syslog.socket
dirPerm /var/log 755 0:0
mount: /var/log bound on /opt/zram/log.bind.
mount: /opt/zram/log.bind propagation flags changed.
dirMountOpt rw,noatime dirFsType  ext4
zram2 created comp_algorithm=lzo mem_limit=150M disksize=500M
mke2fs 1.44.5 (15-Dec-2018)
fs_types for mke2fs.conf resolution: 'ext4', 'small'
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
128000 inodes, 128000 blocks
6400 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=132120576
4 block groups
32768 blocks per group, 32768 fragments per group
32000 inodes per group
Filesystem UUID: 0fd1fa03-f73b-4256-b614-eadb59af4549
Superblock backups stored on blocks: 
    32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

mount: /dev/zram2 mounted on /opt/zram/zram2.
mount: overlay2 mounted on /var/log.
createZlog no oldlog dir in ztab

[12:47:44] root@openhab:/home/openhabian# 

So we're now back at 3 zram devices (zram0, zram1, zram2).

Eventually remove /usr/local/share/zram-config/zram-device-list* before rebooting. That should get you back to 3 devices (1 swap of those) as defined in ztab, with the updated zram-config let's hope you remain there even when stop/starting ZRAM.

Should I do that by hand each time before I reboot?

[mstormi]

Should I do that by hand each time before I reboot?

Hmm, no. I hope it works now (now= with your recent download of latest zram-config) without a need to do that. If you encounter more than 2(3) zram devices again let me know if you can reproduce that (but a new issue, please).

So do you think your original issue is fixed now ?

[shutterfreak]

I think so, so I'll now close this issue.