Hello:

I think the scary part of all this is what is not being said, which is probably without doubt a much larger picture.

To wit, the fantastic amount of money invested to work on/develop AI at this pace is not to see if they can find a cure for cancer or AIDS.
Those would be a by-product, the fallout so to speak.

The truth is that it is all about more money and more power to those who already hold far too much of that in their hands.

eg:
Huge tech corporations such as Microsoft/IBM/Amazon as well as banks and financial corporations are already laying off workers by the thousands as their back-office jobs are being taken over by software.

Interesting times ...

A.

Hello:

The Dev1 forum does have a 'Search' function. 8^)

That said, I think the answer is here.

Best,

A.

Hello:

Indeed it is.

From what I can make out, the entry for *-display UNCLAIMED reads:

product: Topaz XT [Radeon R7 M260/265 / M340/360 / M440/M445 / 530/535 / 620/625 Mobile]

This AMD card is supported in Linux since 4.2.

See here:

https://linux-hardware.org/index.php?id … -1028-0643

The OP should also post the brand/model of his laptop because it seems not all work properly.

Best,

A.

Hello:

Have you tried the same thing with tty1 to tty6?

I think (as in *seem to recall having read*) that tty7 is different from the rest ie: tty1 to tty6 in that it is usually taken by the Xorg display server.
This would mean that it is in use from the moment you logged in to your system.

Maybe the clue is there?

Best,

A.

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.