zram doesn't start properly after power fail
dimvin opened this issue · 6 comments
boot after power fail results in misconfiguration,
zram-config starts, but doesn't create zdevices, it considers them as already working.
Manual Stop and Start zram service restore functionality.
It will be good to do this automatically, somehow recognizing misconfiguration after power failure
====
pi@raspberrypi:~ $ sudo systemctl status zram-config.service
● zram-config.service - zram-config
Loaded: loaded (/etc/systemd/system/zram-config.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2020-05-08 08:30:09 EEST; 11min ago
Process: 322 ExecStart=/usr/local/bin/zram-config start (code=exited, status=0/SUCCESS)
Main PID: 322 (code=exited, status=0/SUCCESS)
May 08 08:30:09 raspberrypi systemd[1]: Starting zram-config...
May 08 08:30:09 raspberrypi zram-config[322]: entry swap /zram0 zram-config0 already exists as zram.
May 08 08:30:09 raspberrypi zram-config[322]: entry log /zram1 /var/log /log.bind already exists as zram.
May 08 08:30:09 raspberrypi systemd[1]: Started zram-config.
====
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 29.5G 0 part /
====
pi@raspberrypi:~ $ tail /usr/local/share/zram-config/log/zram-config.log
zram-config start 2020-05-08-08:30:09
ztab create swap lz4 250M 750M 75 0 20
ztab create log lz4 50M 150M /var/log /log.bind /opt/zram/oldlog
I guess its 0f145d2
Which its horrible with my memory to come back to code after such a time as I am desparately trying to remember why that was added.
Looking now I am wondering why that was added and seems a simpler option should of been implemented.
Let me have a think and see if memory or grey matter kicks in.
You need to delete the device file on startup such as here
https://github.com/mstormi/openhabian-zram/blob/master/zram-config.service
I agree a simpler option is favorable. But while I did some changes in my own repo (see link), I haven't found a simpler (and reliable) way yet.
I think we will go back to scratch as in without keep this as a branch that any can choose, but Master will prob revert.
That way we can have a look at the service restarts and may just fix why and what is happening there.
Going to call the current openhab if that is OK @mstormi
To be honest this was supposed to be a protest repo of hey distro's sort out your zram tools as they are extremely bad.
I was not expecting them to take this one but was hoping maybe something better than current alternatives was on offer.
Sort of surprised how many are having to resort to this repo and how long this has gone on.
Going to call the current openhab if that is OK @mstormi
Revert if you think it does harm but no need to rename yours, mine (above) is what I use from within openhab.
BTW the service does not properly on shutdown/reboot either, so I've also added https://github.com/mstormi/openhabian-zram/blob/master/zram-sync.service
@mstormi I think we will just revert back as it seems its your additions that seem to of added to this and another service for a service for me is adding unnecessary code as maybe the initial pull request was.
It needs a tidy and simplification not further addition and you have your own repo now, so I guess no problem if we delete those additions.
Thanks
Don't mix two issues. That other service I mentioned is unrelated to this one here. That other one was meant to fix #41 (but it didn't work out anyway for me so I removed it, too).
To fix this one, just add a line to zram-config to remove the device file on boot, see https://github.com/mstormi/openhabian-zram/blob/master/zram-config.service
Remember there was a reason for my additions so you would be losing those fixes if you revert.
Also, while I have my own repo for openhab, that's just to have access if in need to change anything fast.
I'm really not keen on maintaining another branch.