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.

You may want to consider another test before going any further:

Debian 11 (sysvinit)+ext4 + LUKS encryption

This is a little bit different in the setup, but its working fine, when I choose a different
partition for saving the snapshots of the system-drive.  So i put a second, luks-encrypted
Disk (partition) in the system, and I could save the snapshots (rsync) there.

I dont know, if its "normal", because i never use a system-drive as ext4. The failure in
btrfs is, that the subvolume "@" is not found on a luks-encrypted drive, ext4 uses rsync
for snapshots.

Again, I have testet all five version with sysvinit, clean, small install (no clones).
Only the one with ext4 uses rsync, the others btrfs.

Debian 11 (sysvinit) + btrfs + LUKS encryption
Devuan 4 (sysvinit)  + btrfs + LUKS encryption

not working.

Debian 11 (systemd) + btrfs  + LUKS encryption.   <- not tested
Debian 11 (sysvinit)  + btrfs  + no encryption
Debian 11 (sysvinit)  + ext4  + LUKS
Devuan 4 (sysvinit)   + btrfs  + no encryption

are working fine.

Running Timeshift v20.11.1

I'm confused here, please clarify:
The tests above were run with Debian 11 +sysvinit in both cases?

If so, it is a Debian bug because:

Debian 11 (sysvinit) +btrfs + LUKS encryption

should work in exactly the same way as

Debian 11 (systemd) +btrfs + LUKS encryption.

Since this is not happening, I think this would be a bug to report to the Debian devs.

Now, whether the Debian devs will attend to it or not is another matter altogether.

The most important question here:

------
Does it work in Devuan?
ie: Does timeshift work properly in Devuan Chimaera+btrfs + no encryption ?
------

Unless I am mistaken, the timeshift, btrfs and LUKS packages all come direct from the Debian repositories. 
Devuan has no intervention in them as they do not have (?) a dependency on systemd.

It is not a question of trust in LUKS as an encryption system.

Something in the btrfs+LUKS combination is not working properly if systemd is not present

You may want to consider another test before going any further:

Debian 11 (sysvinit)+ext4 + LUKS encryption

Using the most widely used Linux file system should tell you whether the problem lies in btrfs or LUKS.

A problem which would seem to go away if systemd is used.
But here at Dev1 we do not do that. 8^)

Thanks for the effort, weeding out this stuff is hard work.

Best,

A.

First

Debian 11+btrfs + LUKS encryption

Does not work.

Debian 11+btrfs + no encryption

Is working fine (sysvinit)

# uname -a
Linux debian 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux

Timeshift is maybe not able to detect a luks partition correctly. Because
it finds this not in /dev/mapper/crypt, it uses /dev/dm-0 - thats not the way, it should.

I am trusting LUKS.   If I would trust my internall ssd-encryption, there is no need
for a luks-partition, but my encryption should not be with some closed-source crucial-encryption thing.

So, what would be your idea for a well known, tested and stable encryption here?   I do not know.

My next try is, to check void Linux. It is also without systemd and there it should run (without lvm).  This is only to
produce some logfiles, and how timeshift/luks etc. is working there. Maybe not today.

tom

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.

Does not work.

Is working fine (sysv)

Today i got an answer of a Void Linux-User:

But I will not check this all with/without LVM, too.

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^/

To be able to catch Debian developer's eyes (and maybe their interest in the problem) you'd have to be able to report that timeshift+btrfs+LUKS works with Debian Bullseye+systemd but not with Debian Bullseye+sysvinit.

Since Debian is supposed to be able to work with both sysvinit and systemd, you might be successful.
But it seems that getting the developers to actually look into a problem related to/involving sysvinit is not a given.

Thanks for this.
Yes, i think about starting a small test-system with Debian GNU, luks and btrfs to produce some good logfiles and
put this to debian-bugs.  There only two, small outstanding bugs for timeshift there, so maybe this could work.

Check this on sunday and put this in bugs-debian, we will see, what happens next. I'll report here.

tom

Or maybe not.

Here's the thingᵀᴹ :

Not having a systemd dependency, the timeshift package that Devuan uses comes straight from the Debian repositories.
ie: it does not need any sanitising from the Devuan maintainers.

- Beowulf uses v20.11.1-1~bpo10+1
- Chimaera uses v22.11.2-1~bpo11+1
- Daedalus uses v22.11.2-1
- Debian Bullseye (stable) uses 20.11.1-1.

See https://packages.debian.org/search?keyw … ection=all

This means that the bug you are experiencing (wherever it is, timeshift or btrfs) would have to be filed upstream to Debian, not Devuan.
ie: it is a Debian package.

Now ... (yes, nothing is as straightforward as it should be ...)

To be able to catch Debian developer's eyes (and maybe their interest in the problem) you'd have to be able to report that timeshift+btrfs+LUKS works with Debian Bullseye+systemd but not with Debian Bullseye+sysvinit.

Since Debian is supposed to be able to work with both sysvinit and systemd, you might be successful.
But it seems that getting the developers to actually look into a problem related to/involving sysvinit is not a given.

That said, I really don't think they will be interested in whatever happens with MX+systemd vis-a-vis MX+sysvinit even though MX feeds directly from the Debian repositories, so it would be a matter of presenting the proof wrt Debian and asking nicely.

Let me know your thoughts on this.

Thanks in advance.

Best,

A.

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.

I am using first debian, then devuan unstable for a long time with not that much bad experiences.

Really good point.   So i did.

[06:46:17] D: Vertrieb: devuan "4"
[06:46:17] Vertrieb: devuan "4"
[06:46:17] D: DIST_ID: devuan
[06:46:17] DIST_ID: devuan
...
[06:46:18] detect_system_devices()
[06:46:18] D: / wurde dem Gerät zugeordnet: /dev/dm-0, UUID=
[06:46:18] / wurde dem Gerät zugeordnet: /dev/dm-0, UUID=
[06:46:18] D: /boot wurde dem Gerät zugeordnet: /dev/sda1, UUID=0a8d3a38-9894-4600-8e94-8680f3f1df36
[06:46:18] /boot wurde dem Gerät zugeordnet: /dev/sda1, UUID=0a8d3a38-9894-4600-8e94-8680f3f1df36
[06:46:18] D: Searching subvolume for system at path: /
[06:46:18] Searching subvolume for system at path: /
[06:46:18] D: Found subvolume: @, on device: /dev/dm-0
[06:46:18] Found subvolume: @, on device: /dev/dm-0
...
[06:46:22] btrfs_mode=true
[06:46:22] D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] D: Schnappschussgerät: '/dev/sda'
[06:46:22] Schnappschussgerät: '/dev/sda'
[06:46:22] D: Schnappschussort: 
[06:46:22] Schnappschussort: 
[06:46:22] D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] D: Bitte BTRFS-Systemlaufwerk mit Wurzelunterlaufwerk (@) auswählen
[06:46:22] Bitte BTRFS-Systemlaufwerk mit Wurzelunterlaufwerk (@) auswählen
[06:46:22] D: Status: NO_BTRFS_SYSTEM
...
[06:46:22] btrfs_mode=true
[06:46:22] D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] D: Schnappschussgerät: '/dev/dm-0'
[06:46:22] Schnappschussgerät: '/dev/dm-0'
[06:46:22] D: Schnappschussort: 
[06:46:22] Schnappschussort: 
[06:46:22] D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
[06:46:22] D: Bitte BTRFS-Systemlaufwerk mit Wurzelunterlaufwerk (@) auswählen
[06:46:22] Bitte BTRFS-Systemlaufwerk mit Wurzelunterlaufwerk (@) auswählen
[06:46:22] D: Status: NO_BTRFS_SYSTEM

# uname -a
Linux devuan 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux

# btrfs subvolume list /
ID 256 gen 9331 top level 5 path @

Running Timeshift v20.11.1

Thanks for your time.

You're welcome.

I have the persistent feeling that this may be related to the fact that you are running Ceres, which (by definition/design) is unstable and prone to this sort of problem. ie: it has quite a bit of loose ends.

You may want to consider setting up a Chimaera system with a btrfs/LUKS just to rule that out.

Best,

A.

~$

Downloaded the Version of backports, like you described, doesnt run on my system.

Then, i compiled the archived version without any luck, same result:

$ sudo timeshift-gtk --debug

D: Vertrieb: devuan "5"
D: DIST_ID: devuan
...
D: Searching subvolume for system at path: /
D: Found subvolume: @, on device: /dev/dm-0
D: Found subvolume: @home, on device: /dev/dm-0
D: Found subvolume: @daten, on device: /dev/dm-0
D: Found subvolume: @Virtual, on device: /dev/dm-0
...
** (timeshift-gtk:9068): CRITICAL **: 02:53:38.007: tee_jee_file_system_dir_exists: assertion 'dir_path != NULL' failed
D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
D: Schnappschussgerät: '/dev/dm-0'
D: Schnappschussort:
D: Ausgewähltes Schnappschussgerät ist kein Systemlaufwerk
D: Bitte BTRFS-Systemlaufwerk mit Wurzelunterlaufwerk (@) auswählen
D: Status: NO_BTRFS_SYSTEM

too late for more ideas now, i will try more later.

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.