Your system today obviously is different from the one the image would get you, so YES.
You need to reinstall anyway so where’s the point in asking that [a rhetorical question that is].
No I’m not gonna help people with working around the recommended installation procedure.
No, actually I do not need to reinstall anything.
I also have the choices of abandoning this zram feature or just try and tolerate any strange behaviors.
My ups solution expects a clean buster install to solve all preconditions for setting it up. It apparently can not, easily, be installed on a “lite” openhabian image (of-course it could be if one possesses the needed insight).
Both openhab and openhabian offers the choice of installing them as packages, perhaps this choice should be removed if the bugs aren’t dealt with on all flanks.
Perhaps an additional text could be added to the warning notice presented when choosing to install the zram feature. “This is an even more hazardous action if the openhabian install isn’t part of the openhabian image distribution.”
When in your opinion did I deviate from the recommended install procedure? Where does it say that one has to start from the openhabian image and that problems will most likely come if using the apt-get install of openhabian?
Thank you for your very friendly answers, without any emotional tendencies [irony that was].
As I said, I gave you the background to my setup in my first post. You failed to pay attention.
Sure, choice is yours. It just happens to be the fastest solution. Use NUT for your UPS.
It’s always the same story. People think they’re more clever than those to bundle distros, hence choose to ignore the recommendations and when it doesn’t work they complain “hey but you didn’t tell me I may not do XXX so that is expected to work”.
No it isn’t. That’s not how the world and how SW development works, let alone in complex all-volunteer’s projects like this.
Any developer can develop, test and debug against a defined environment ONLY.
That means a need to define a starting point such as and an unmodified Raspbian (hence the image).
That implies that if you deviate from that (“I haven’t done that many changes to the vanilla buster release”) and something fails thereafter while on the unchanged system it works ok then it must have been caused by your changes. And it means that noone but you can know what it was, so don’t try inverting responsibilities.
Yes you did but one literally had to search for it. And you didn’t mention your changes. You didn’t mention the UPS. You use vague and somewhat incomprehensible and misunderstandable wording. You’ve put it below an awkwardly large code window instead of at the beginning where it belongs.
Possibly because you were afraid people wouldn’t care about your post if they read about the modifications upfront (no offense, yes I’m guessing here and I may be wrong in doing so. But that is an often encountered pattern to observe).
irony on which part, the one before or the one after the comma ? Makes for a huge difference.
To me it reads like you’re lacking the respect for work and time others spend to enable and help you (for free, needless to say).
If you want help you have to play by the helper’s rules.
If you don’t want to do that you may not expect anybody to spend any of his time.
Well I thought the PiJuice solution was a quite nice and adequate solution. So, its a Pi hat with a pretty nice software available. I’m reluctant to spend too much time getting a UPS solution in operation. Haven’t heard about NUT before.
Well still, I really tried following the mentioned preconditions. I cant setup an isolated system just to evaluate the zram feature. I’m using my setup as my “production system” and thus I’ve added some extra features, the UPS hat is the only additional one I can think of except whats being offered from the openhabian-config tool.
But by adding this external feature I might not be suitable as a beta tester of the zram addition. If so, I’ll try to live with these kinds of effects until zram is published as a proven and production ready feature.
That being said, my problem might not originate from zram anyhow. You mentioned a fix concerning a journal issue, I’ll take that lead and see where it takes me.
I’ll keep that in mind, I wasn’t trying to fool anyone.
The irony was aimed at both sides of the comma. My English grammar can certainly be improved.
I’m not expecting support for free (even though it is as its community driven). And I don’t mean no disrespect, I now or at least assume that you spend a lot of time and effort on this. But both you and me are in to this because we also think its fun. I’m quite impressed by your quick replies. But there is no need for the attitude.
If my “production system” can be of use in evaluating and giving you feedback on the zram feature I believe that would be helpful for both of us and the community.
To conclude, for my present problem, I’ll look somewhere else for a solution.
Thanks! And thanks for the bickering, I partly blame Covid-19.
It’s software compatible with any UPS, meaning you wouldn’t need to install anything hence won’t need vanilla Raspbian. There’s even an openHAB binding.
Very likely so. Use journalctl -q --vacuum-time=30d (or less) to prune logs, see functions/system.bash. Depending on when you’ve setup your system, that may or may not have been present at install time.
Never mind. Yes I need to get some fresh air, too.
1 Like
Well, that’s a bit short 
to be fair. You have to install NUT (network ups tools) and you have to chose the correct drivers. Not every UPS is working, but sure enough, most of them 
The setup is at least a bit more complex than most of the manufacturer’s software, as you have to configure the UPS type and so on.
What Sizes would you recommend for zram on RPi4 8GB?
My zram2 is pretty full with logs on the default settings:
/dev/zram1 870M 3.6M 806M 1% /opt/zram/zram1
overlay1 870M 3.6M 806M 1% /var/lib/openhab/persistence
/dev/zram2 575M 496M 38M 93% /opt/zram/zram2
overlay2 575M 496M 38M 93% /var/log
while
/dev/zram2 zstd 600M 415.6M 49.1M 200M 4 /opt/zram/zram2
/dev/zram1 zstd 900M 21.3M 1.3M 10.7M 4 /opt/zram/zram1
/dev/zram0 lzo-rle 600M 4K 87B 4K 4 [SWAP]
Just increase it. Or prune OH logs. There is no recommendation.
Wow, you are lighning fast 
Will do, thank you!
I know this post has been solved. But, it seems more related to openHABian. I use manual installation for my SBC. May I know which configuration file should I manually change that will not override after each update to move persistence, cache and logs to ZRAM? I am using ARMBIAN for your info: For logs, there is an environment variable to move log files to another directory, how about persistence and cache? Thanks.
ZRAM works the other way around, it does an overlay file system that is virtually on /var/log/openhab/ So openhab uses its normal configuration.
This thread is exclusive to openHABian.
So don’t apply statements on ZRAM (in openHABian) to your system.
AFAIK Armbian puts all of / on ZRAM, albeit not with the overlayfs we use in openHABian.
I’d recommend you move over to openHABian or if you want to keep using Armbian please go look elsewhere for help, chances for a misunderstanding are too big here.