Hello:

I can relate to that.

I do not ever use screensavers as I find them both annoying and a complete waste of CPU cycles.
That and the usually poor performing power management apps of any OS I have used.
That said, my main box is not a laptop so YMMV.

In the rare occasion I use my Asus 1000HE on batteries, I just resort to the basic screen blanking.

I'd say that a Devuan live *.iso has many uses, the main one being for new users to try, recovery is really not the best example.
There is many a specialised *.iso for that type of work, usually with a very complete array of rescue tools present.

One of the first ones I came across, knoppix, comes to mind.
I always have one, ready to use, on a 16Gb USB key.

Best,

A.

Hello:

OK

Debian 11 (sysvinit) is (to all intents and purposes) the same as Devuan 4 (sysvinit)

and timeshift works properly with

ext4+LUKS - or - btrfs+no encryption

But does not work properly with

btrfs+LUKS encryption

It does not seem to be a timeshift or btrfs problem to me.

And although none of the packages involved have systemd as a dependency, it would seem the problem gets solved by the presence of systemd in the installation.

From your OP:

I think that a bug report on this problem would have to be filed against LUKS with the Debian devs.
See https://www.debian.org/Bugs/Reporting

Thanks for the effort.
Please keep us posted.

Best,

A.

Hello:

Yes, we knew that Devuan Chimaera+btrfs + LUKS encryption did not work.
I also thought I knew how to spell Devuan.  B^/

Good to know.
Seems that timeshift may be be in the clear.

Now you have to be able to rule out something going haywire when btrfs is used with encryption other than LUKS.
It would have to be a widely used and tested encyption package, nothing esoteric.

Fo that, the next test would be to try Devuan Chimaera+btrfs + some other encryption.

Thanks for the effort.

Best,

A.

Hello:

You're welcome.

Thank you very much for that.  8^)
It could/would start things rolling with the people at Debian.

And maybe get to the root of the problem.

From where I stand, it would not seem to be a bug in timeshift itself.
ie: it works perfectly well without systemd in Devuan, where it is not a dependency.

But it has severe problems if the file system is btrfs and uses LUKS encryption.
From what I have read, btrfs does not support encryption at file system level like ext4 does, needing a third party solution for that.

----
Could it be that btrfs + LUKS have some problem that (somehow) systemd solves or hides?
----

For completeness sake and to rule that out, you may want to consider first doing two control tests with Devuan Chimaera:

The setup known to fail ...
ie: Devuan Chimaera+btrfs + LUKS encryption

... compared to

Devuan Chimaera+btrfs + no encryption

If it does not work then it is a btrfs problem in Devuan as we know that Devuan Chimaera with ext4 works.

If it works, the next step would be to try some other third party encryption solution to see if it is a LUKS encryption induced problem.

If a different encryption solution works, then it is a LUKS problem.

Which would leave us firmly in Devuan territory.     
ie: the LUKS package evidently needing systemd to work, at least with btrfs.

If the problem persists, then you can move on to Debian territory.

The other tests would be:

1. the one known to work ...
ie: Debian Bullseye+systemd+btrfs + LUKS encryption

... compared to

a. Debian Bullseye+sysvinit+btrfs + no encryption

b. Debian Bullseye+sysvinit+btrfs + LUKS encryption

Please bear in mind that the Debian tests must use a Debian Bullseye stable installation and packages from the Debian repositories.
Obviously, with no mention of MX or Devuan.

Right.
Again, thank you very much for this.

Best,

A.

Edit: Devuan spelled wrong ...  B^/

Hello:

So much for persistent feelings. 8^/

The only suggestion I can make at this point is to file a bug report against timeshift 20.11.1-1 with Devuan,
pointing out that it seems to work properly in a systemd environment.

ie:

In parallel, you may want to consider reaching out to teejee2008 to see if he has something to say about this.

Please keep us posted.

Best,

A.

Hello:

I have been using timeshift for the longest while, now version 20.11.1 on Devuan Beowulf with a backported kernel:

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ 

~$ apt list | grep installed | grep shift
--- snip ---
timeshift/oldstable-backports,now 20.11.1-1~bpo10+1 amd64 [installed]
~$ 

No systemd in my box and as far as I can tell, it is working properly, but there is no btrfs or LUKS in use.

Now, according to the project page page, timeshift is now maintained by the LinuxMint project.
The teejee2008 repository has been archived.

And it would seem that although Linux Mint is systemd able, it is up to the user to both install it and choose to use it.

Maybe some systemd crap trickled into timeshift?
Could well be ...

Maybe it is something related to LUKS encritped? 
No idea.

But it would be a real pity to see a neat/useful application such as timeshift get poisoned by systemd crap.

Edit:

See posts by the original timeshift author, here and here.

So, if the original version works, you may want to stick with it for the time being.

If not, maybe contacting teejee2008 to ask about this would get you an answer to the problem.
It seems that he is open to seeing about bug fixes and minor changes.

Best,

A.

Hello:

Yes.
I've checked and there are two lines missing in the backported /usr/lib/rsyslog/rsyslog-rotate file.

Congratulations!
------------------------------
You have found a bug.
------------------------------

Now, please file a report so it gets fixed.

That said:

Bear in mind that Devuan survives today thanks to a small but very dedicated cast of knowlegeable individuals who devote their time and effort to keep it running.

Doing that, with the resources the Devuan project has at hand, is no small feat.
By any means: it is an endless task.

Unfortunately, as systemd and other assorted crap (eg.: zeigeist) advance and dig their tentacles into the workings of Debian, that task becomes more and more difficult.

It is something most people are not aware of.

                    -----------------------------------> You seem to be one of them. <-----------------------------------

Indeed ...
There are a few 'somebodies' who sanitise Debian packages for their use in Devuan.
But not nearly enough of them. (see above)

I'm sorry to have to break it to you: it is not the first time and it won't be the last.
Please take note of that.

That is how it works with any OS.
Linux is no exception.  ie: shit happens

Fortunately, it seldom happens in Devuan.

Ahhh ...
I am (very) sorry to hear that.
Really.

Mainly because, if I take you to your word, you will most probably leave the ever growing Devuan user base.
Which is a real pity as Devuan could use another 'somebody', more so if it is one with your bug-tracking skills.

See above.

If you need the type of trust and assurances that Debian has given/gives you, you may want to consider going back to Debian.

I'm sure they have no bugs (undetected/outstanding/won't-fix) to speak of.
ie: if you don't take systemd into account.

Now: close your eyes, take a deep breath, relax while you have a cuppa while you file the report with Devuan.

You'll feel better afterwards.

Best,

A.

Hello:

Just to add: I have experienced exactly that type of thing when reporting issues related to windows crashing in XFCE.
As a result, I decided to be rid of XFCE as soon as I can get together my Chimaera/Openbox act.

Best,

A.

Hello:

Quite so, it is yet another reason I am still on Beowulf.

Fortunately (unlike Wicd which is abandoned) it is getting worked on again.

See here.

Kudos and a big Thank You to Robert Pierce for stepping up to save SLiM.

Best,

A.

Hello:

Indeed ...

"We need free software.
Unless we control the software in the network, the network will in the end control us."

Thanks for that.

Best,

A.