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.

Hello:

Please do.

Not that you know of.

Indeed ...

I think that what is annoying is that something (unknown to you) is creating a .config dir in /.

And from what I have been told, it should not be happening.
Unless at some time your $HOME was set to /.
Which does not seem to be the case.

Granted, it may not be a big deal, but it should not be happening.

My idea of things like these is that they should be investigated and fixed.
If it is a bug or an oversight, it should be squashed/fixed.

All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.

Of course, YMMV.

Best,

A.

Hello:

Hmm ...
No idea.
Have not tried it but I don't see (?) why it shouldn't.

Yes, I guess I could pin it.
ie: the same way I do with pulseaudio and see what happens on the next upgrade.

Bear in mind that there are other apparmor related libraries which are/may be needed by other packages.

eg: libapparmor1

~$ aptitude why libapparmor1
i   stress-ng Depends libapparmor1 (>= 2.10)
~$ 

Edit:

It seems that there's more than stress-ng involved with libapparmor1.

~$ aptitude why libapparmor1
i   slim Depends dbus                    
i A dbus Depends libapparmor1 (>= 2.8.94)
~$

---> Very strange all this did not show up on my previous query to aptitude. <---

I have not used stress-ng in years, so I might as well get rid of it. and solve the issue.

We'll see how the pinning goes.

Best,

A.