ZRAM status

You’re welcome.Way too many people not to honor this, and after all, that’s why I/we all do it for.

I don’t get that, why would you need to stop it for the backup ?
If you use Amanda you can simply tell it to backup /var/lib/openhab2 (= /srv/openhab2-userdata, even using that should work).

I tried to install, but got an error '…during execution of: “30 | System Settings” ’
image

I only had a quick look at the document mentioned, … maybe there’s a less painfull solution.

I’m running oh on a raspi 3B+ based on an older openhabianpi image (before march 2018).
uname -r gives me 4.19.66-v7+

What i did:
I switched to master and updated the system.
When trying to install zram, it failed with error shown above. After leaving openhabian-config the console shows

$ apt-get install -y -q --no-install-recommends make libattr1-dev
Paketlisten werden gelesen…
Abhängigkeitsbaum wird aufgebaut…
Statusinformationen werden eingelesen…
libattr1-dev ist schon die neueste Version (1:2.4.47-2).
make ist schon die neueste Version (4.1-9.1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Hinweis: Checke ‘37154cf83254e703b3696e82cfd824724ff1a16d’ aus.

Sie befinden sich im Zustand eines ‘lösgelösten HEAD’. Sie können sich
umschauen, experimentelle Änderungen vornehmen und diese committen, und
Sie können alle möglichen Commits, die Sie in diesem Zustand machen,
ohne Auswirkungen auf irgendeinen Branch verwerfen, indem Sie einen
weiteren Checkout durchführen.

Wenn Sie einen neuen Branch erstellen möchten, um Ihre erstellten Commits
zu behalten, können Sie das (jetzt oder später) durch einen weiteren Checkout
mit der Option -b tun. Beispiel:

git checkout -b

/opt/zram
gcc -Wall -std=c99 -c main.c
gcc -Wall -std=c99 -c logic.c
gcc -Wall -std=c99 -c sh.c
gcc -lm main.o logic.o sh.o -o overlay
/bin/sh: 0: Can’t open ./install.sh

$ systemctl start zram-config
Failed to start zram-config.service: Unit zram-config.service not found.

Any hints?

I’m running oh on a raspi 3B+ based on an older openhabianpi image (before march 2018).
uname -r gives me 4.19.66-v7+

This is old! I periodically (once per year) start from a fresh install in order to remain aligned with the current version. With the openhab backup and restore it should not be too complex, even though I prefer to activate bindings one at a time and transfer the textual configurations accordingly.
Either way, it should take less time than trying to figure out how to make new scripts work on old systems.
Just my 2cents…

Hi I tried to install Zram on fresh install of openhabian ,the above error,read here and see that zram is automatically installed now on latest openhabian ,so maybe this error just says that it’s already installed ?

I thought about that at times. But than something else gained priority. Also not having documented everything i changed since starting gives me e bit of a pain.

Is updating the distribution an option?

Because life of my openhabianpi does not depend on zram being installed today or tomorrow (hopefully), i’d like to know, if this error is expected in a situation like mine. If not, maybe Markus needs some more info.

Try again, there has been a fix to this.

Of course, it always is. But it won’t fix your issue.
@Lionello_Marrelli no need to install from scratch (doesn’t harm, though).

1 Like

Looks good at the first glance:

no error from openhabian-config.

console shows:

$ apt-get install -y -q --no-install-recommends make libattr1-dev
Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
libattr1-dev ist schon die neueste Version (1:2.4.47-2).
make ist schon die neueste Version (4.1-9.1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Hinweis: Checke '37154cf83254e703b3696e82cfd824724ff1a16d' aus.

Sie befinden sich im Zustand eines 'lösgelösten HEAD'. Sie können sich
umschauen, experimentelle Änderungen vornehmen und diese committen, und
Sie können alle möglichen Commits, die Sie in diesem Zustand machen,
ohne Auswirkungen auf irgendeinen Branch verwerfen, indem Sie einen
weiteren Checkout durchführen.

Wenn Sie einen neuen Branch erstellen möchten, um Ihre erstellten Commits
zu behalten, können Sie das (jetzt oder später) durch einen weiteren Checkout
mit der Option -b tun. Beispiel:

  git checkout -b <neuer-Branchname>

gcc -Wall -std=c99 -c main.c
gcc -Wall -std=c99 -c logic.c
gcc -Wall -std=c99 -c sh.c
gcc -lm main.o logic.o sh.o -o overlay
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
libattr1-dev ist schon die neueste Version (1:2.4.47-2).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Klone nach 'overlayfs-tools' ...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 96 (delta 0), reused 3 (delta 0), pack-reused 92
Entpacke Objekte: 100% (96/96), Fertig.
gcc -Wall -std=c99 -c main.c
gcc -Wall -std=c99 -c logic.c
gcc -Wall -std=c99 -c sh.c
gcc -lm main.o logic.o sh.o -o overlay
Created symlink /etc/systemd/system/basic.target.wants/zram-config.service → /etc/systemd/system/zram-config.service.
#####          Reboot to activate zram-config         #####
#####       edit /etc/ztab to configure options       #####

$ systemctl start zram-config

After reboot everything looks fine:

# zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo           600M    4K   89B   12K       4 [SWAP]
/dev/zram1 lzo           500M 16,5M 17,4K  184K       4 /opt/zram/zram1
/dev/zram2 lzo           500M   32M  3,9M  4,4M       4 /opt/zram/zram2

Thx. Quite painless! :slight_smile:

I just wanted to have a look at openhab.log and used the windows-mounted share /srv to open the file. Then i realized that one to be out of date.

I understand that /srv/… are mounts of the original dirs. I do not understand what mount command shows me:

/dev/mmcblk0p2 on /srv/openhab2-conf type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-addons 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/mmcblk0p2 on /srv/openhab2-userdata 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)
/dev/mmcblk0p2 on /opt/zram/persistence.bind type ext4 (rw,noatime)
/dev/zram1 on /opt/zram/zram1 type ext4 (rw,noatime)
overlay1 on /var/lib/openhab2/persistence type overlay (rw,relatime,lowerdir=/opt/zram/persistence.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
overlay1 on /srv/openhab2-userdata/persistence type overlay (rw,relatime,lowerdir=/opt/zram/persistence.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)

@mstormi: is this even accepted or intended?

Any “good” way to work around this? Or did i just miss something?

mounts look fine but they should have the live files. They do on my just installed box.
Do you have unit files /etc/systemd/system/*openhab* ?
Can you switch to master branch, update openhabian-config and select menu 13 ?

No, i don’t. Only ./openhab2.service.d/override.conf exists there.

Shure. Some problem with “umount -q …” there:

2020-06-18_20:12:06_CEST [openHABian] Checking for root privileges... OK
2020-06-18_20:12:06_CEST [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2020-06-18_20:12:06_CEST [openHABian] openHABian configuration tool version: [master]v1.5-664(0ea3bb8)
2020-06-18_20:12:07_CEST [openHABian] Checking for changes in origin branch HEAD ... OK
2020-06-18_20:12:35_CEST [openHABian] Switching to branch  ... warning: Leere Strings als Pfadspezifikationen werden in kommenden                                                                                  Releases ungültig.
Bitte benutzen Sie stattdessen . wenn Sie alle Pfade meinen.
OK
2020-06-18_20:12:48_CEST [openHABian] Updating Linux package information ... OK
2020-06-18_20:12:48_CEST [openHABian] Preparing openHAB folder mounts under /srv/...
$ systemctl is-active --quiet smbd

$ systemctl is-active --quiet zram-config

$ umount -q /srv/openhab2-sys /srv/openhab2-conf /srv/openhab2-userdata /srv/openhab2-logs /srv/openhab2-addons
umount: Ungültige Option -- q

Usage:
 umount [-hV]
 umount -a [options]
 umount [options] <source> | <directory>

Unmount filesystems.

Options:
 -a, --all               unmount all filesystems
 -A, --all-targets       unmount all mountpoints for the given device in the
                           current namespace
 -c, --no-canonicalize   don't canonicalize paths
 -d, --detach-loop       if mounted loop device, also free this loop device
     --fake              dry run; skip the umount(2) syscall
 -f, --force             force unmount (in case of an unreachable NFS system)
 -i, --internal-only     don't call the umount.<type> helpers
 -n, --no-mtab           don't write to /etc/mtab
 -l, --lazy              detach the filesystem now, clean up things later
 -O, --test-opts <list>  limit the set of filesystems (use with -a)
 -R, --recursive         recursively unmount a target with all its children
 -r, --read-only         in case unmounting fails, try to remount read-only
 -t, --types <list>      limit the set of filesystem types
 -v, --verbose           say what is being done

 -h, --help     display this help and exit
 -V, --version  output version information and exit

For more details see umount(8).

$ rm -f /etc/systemd/system/srv*.mount

$ mkdir -p /srv/openhab2-sys /srv/openhab2-conf /srv/openhab2-userdata /srv/openhab2-logs /srv/openhab2-addons

$ cp /opt/openhabian/includes/srv_readme.txt /srv/README.txt

$ chmod ugo+w /srv /srv/README.txt

$ create_mount /usr/share/openhab2 sys
Created symlink /etc/systemd/system/multi-user.target.wants/srv-openhab2\x2dsys.mount → /etc/systemd/system/srv-openhab2\x2dsys.mo                                                                                 unt.

$ create_mount /etc/openhab2 conf
Created symlink /etc/systemd/system/multi-user.target.wants/srv-openhab2\x2dconf.mount → /etc/systemd/system/srv-openhab2\x2dconf.                                                                                 mount.

$ create_mount /var/lib/openhab2 userdata
Created symlink /etc/systemd/system/multi-user.target.wants/srv-openhab2\x2duserdata.mount → /etc/systemd/system/srv-openhab2\x2du                                                                                 serdata.mount.

$ create_mount /var/log/openhab2 logs
Created symlink /etc/systemd/system/multi-user.target.wants/srv-openhab2\x2dlogs.mount → /etc/systemd/system/srv-openhab2\x2dlogs.                                                                                 mount.

$ create_mount /usr/share/openhab2/addons addons
Created symlink /etc/systemd/system/multi-user.target.wants/srv-openhab2\x2daddons.mount → /etc/systemd/system/srv-openhab2\x2dadd                                                                                 ons.mount.
OK
2020-06-18_20:12:54_CEST [openHABian] Applying miscellaneous system settings...
$ setcap cap_net_raw,cap_net_admin=+eip cap_net_bind_service=+ep /opt/jdk/zulu11.39.61-ca-jdk11.0.7-linux_aarch32hf/bin/java

$ setcap cap_net_raw,cap_net_admin=+eip cap_net_bind_service=+ep /usr/sbin/arping

$ echo Creating persistent systemd journal folder location: /var/log/journal
Creating persistent systemd journal folder location: /var/log/journal

$ echo Keeping at most 30 days of systemd journal entries
Keeping at most 30 days of systemd journal entries
Deleted archived journal /run/log/journal/465f4052ffee4d3496b601232eae06c4/system@3a1973a7710542e097d1117402a7276a-000000000000000                                                                                 1-00054068b8b224ce.journal (6.0M).
Deleted archived journal /run/log/journal/465f4052ffee4d3496b601232eae06c4/system@3a1973a7710542e097d1117402a7276a-00000000000000c                                                                                 9-00054068b8b387f3.journal (6.0M).
Vacuuming done, freed 12.1M of archived journals from /run/log/journal/465f4052ffee4d3496b601232eae06c4.
OK

The result looks good, though:

[20:22:24] openhabian@openHABianPi:~$ ls -l /srv/openhab2-logs/openhab.log
-rw-rw-r-- 1 openhab openhab 5106411 Jun 18 19:51 /srv/openhab2-logs/openhab.log
[20:22:42] openhabian@openHABianPi:~$ ls -l /var/log/openhab2/openhab.log
-rw-rw-r-- 1 openhab openhab 5106411 Jun 18 19:51 /var/log/openhab2/openhab.log
[20:22:51] openhabian@openHABianPi:~$ ls -l /srv/openhab2-logs/events.log
-rw-rw-r-- 1 openhab openhab 11169932 Jun 18 20:12 /srv/openhab2-logs/events.log
[20:22:57] openhabian@openHABianPi:~$ ls -l /var/log/openhab2/events.log
-rw-rw-r-- 1 openhab openhab 11169932 Jun 18 20:12 /var/log/openhab2/events.log
[20:23:03] openhabian@openHABianPi:~$ tail /var/log/openhab2/events.log

Do you run some older release ? On my buster, -q is a known option.

quite old, yes.
uname -r tells me 4.19.66-v7+
Distrib is from early 2018 i think (i just looked up: stretch it is).
This is why i asked, if dist-upgrade would be an option.

EDIT:
After restarting openhab because i di see no more updates in the logs, i got lot’s of messages on the webinterface. I did a reboot with oh disabled. Fine. Started oh:

Job for openhab2.service failed because the control process exited with error code.
See "systemctl status openhab2.service" and "journalctl -xe" for details.

Wastebin is not so far away any more.

With zram “uninstalled” via openhabian-config and running an other update which installed java once more, i’m now able to run openhab again.

Do you think, i should give zram another chance an if so: which way? Or should i update to buster before @mstormi?

Sure. Upgrade to buster first, upgrade to latest openhabian, then install ZRAM from the menu.
Or if you want to be on the safe side, reinstall.
Wait a couple of days for the updated image to get released.

Thx for your recommendation.

I’ll go for a fresh install i think. I’ll take some time before and go through all my dirty changes in the dark past and make some more notes to be prepared.

Thank you again for taking your time!

Ok I’m a bit lost on the ZRAM topic. I have installed openHAB version 2.5.2-1 (running on openhabian) and running it for about 4 month with ZRAM enabled on a Raspberry Pi 4 Model B Rev 1.1. I’d like to upgrade to the latest openhabian + openHAB version.

What is the right way to do it with ZRAM being enabled? (I can’t find anything in the first post)

Stop zram-config, update OH, edit /etc/ztab to match latest, reboot

1 Like

Thank you very much. Should I reinstall ZRAM (in the openhabian config) after updating to the latest openhabian version? Or is that not necessary?

no it isn’t

Thank you very much that did work perfectly. On a system reboot is stopping OH2 and rebooting (sudo reboot) enough or is there a special treatment still necessary? Or is it enough to use just a sudo reboot?