I think /etc/systemd/system/zram-config.service was overwritten because these changes are not yet in the openhabian repo. Manually edit and daemon-reload again. Also check /usr/local/bin/zram-config but if I was to guess that is up to date.
I edited /etc/systemd/system/zram-config.service and performed daemon-reload. I had to copy /usr/local/bin/zram-config from github, because it was not up to date.
After first reboot zram-config was not active.
I restarted it manually but the mounts disappeared.
After subsequent reboots all srv mounts were not there.
I reapplied option 13 and 38 with openhabian-config: now the mounts are ok after reboot. I would conclude that the github version does not work in my box. In anycase the system works now and I have to let it run.
Thank you for your help,
LionHe
Thanks for yours. I know it’s a confusing hassle to manually install like this.
Just for my understanding: You think that the current Github version of zram-config, i.e. https://raw.githubusercontent.com/mstormi/openhabian-zram/master/zram-config does not work for you?
When you applied option 38, openhabian-config should have downloaded and installed exactly that file that the link points to. Could you please compare your file with the link and send me the diff if any?
I checked this morning and the version of the script in /usr/local/bin is exactly the same as the one I downloaded from github yesterday morning. Checking at status of zram-config.service, It actually gives the file not found error for /boot/cmdline.txt. Sorry for the wrong conclusion of yesterday evening.
As you said, there should be something weird on my box, as it seems to behave differently after reboot sometimes.
Ok. Does it all work as expected now (except for that cmdline message) ?
Sorry for late reply. My system is stable but still not reproducible after reboot.
Mounts were correct./srv/openhab-logs and /var/log/openhab2 coincided and the same applied to /srv/openhab-userdata and /var/lib/openhab2.
Then I stopped openhab2 in order to perform a backup (I did not stop zram-config this time) and I noticed that two aforementioned /srv/ directories were empty. I then rebooted and everything worked again. The backup contains the updated events.log and after reboot the logs and persistence were there, indicating that zram-config stored them in the sd. Unfortunately charts were not displaying (error in chart generation: Null), even though data was accessible through the REST API. I therefore tried rebooting (without stopping openhab this time ): after reboot charts were working but all recent changes in persistence were lost. Now the system behaves as expected: next time I will try to stop openhab before reboot.
If your /etc/systemd/system/zram-config.service looks like this, then shutting down OH also shuts down ZRAM due to “PartOf”, that’s probably why /srv was empty.
Rebooting should also trigger the stop of OH (and ZRAM) so the result should be the same.
Your chart issues are probably unrelated. At times you need to start OH twice.
[Unit]
Description=zram-config
After=local-fs.target
Before=reboot.target halt.target smbd.service openhab2.service
PartOf=openhab2.service
1 Like
Maybe in my system the ‘reboot now’ command does not wait the completion of the other services, or there’s a shorter timeout.
In any case, again, thank for your support of the community
LionHe
I thought that of mine, too. But while it quickly disconnects all networking, it actually doesn’t boot right after but syncs to disk first. Have another look at yours.
Just FYI, just saw that /boot/cmdline.txt missing myself.
Reason ultimately was that /etc/fstab was gone so it couldn’t mount /boot. ZRAM also didn’t start and / was readonly. Added fstab from backup and it worked again on next reboot.
I checked fstab and there is no line concerning /boot.
But it is mounted in my system
$ mount | grep boot
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
Should I add to /etc/fstaba line like the following
/dev/mmcblk0p1 /boot vfat defaults 0 2
As you say it IS mounted - no. There’s regular means beyond fstab to mount stuff in the proper stage of the boot process.
Yes if your /etc/fstab does not contain anything about /boot you could try to add that, just to see if it makes a difference (although I think the mount must happen elsewhere as at that stage when the boot loader gives that output, Linux kernel is not yet running).
Check /boot/cmdline.txt. It likely has arguments UUID= or PARTUUID= with your partition ID.
Run /sbin/blkid to get all of these output for your HW.
1 Like
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.