The officially official Devuan Forum!

tom

Member

Registered: 2022-02-03

Posts: 15  

bug: timeshift doesnt work with LUKS encrypted /

Trying to get "timeshift" working on my devuan GNU ceres.  But only get this errror:

~# timeshift --check
E: System disk not found!

Also:

https://github.com/teejee2008/timeshift/issues/862
btrfs partition in LUKS device mapper not recognized

4L3XK commented Feb 2, 2022 •
It seems timeshift need systemd to properly recognize and process a btrfs volume in a LUKS partition.
Booting the system with systemd as init made the btrfs partition available and now snapshotting is working nicely.
The system in use in this issue is MX Linux which uses sysvinit as standard init, hence the problem.

Any advice about this?
Maybe using a (really) old version of timeshift?  Or compile this by myself?

Thanks.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

4L3XK commented Feb 2, 2022 •
It seems timeshift need systemd ...

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.

Installing the systemd package will not switch your init system unless you boot with init=/lib/systemd/systemd or install systemd-sysv in addition.

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.

Linux Mint is maintaining a forked version of Timeshift and they are planning to develop it further. This repo will continue to be available but will only see bug fixes and minor changes. You will have an option to use either this version or the fork developed by Linux Mint.

Sorry. No plans to close this repo. There's already a message redirecting to the Linux Mint fork. The version of Timeshift in this repo will continue to be available for those who need it.

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.

Last edited by Altoid (2023-03-29 12:23:42)

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

Thanks for your answer!

~$

Sorry. No plans to close this repo. There's already a message redirecting to the Linux Mint fork. The version of Timeshift in this repo will continue to be available for those who need it.

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.

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.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

Thanks ...

You're welcome.

Downloaded the Version of backports ...

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.

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hi,

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.

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

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

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.

Last edited by tom (2023-03-30 03:07:45)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

... good point.   So i did.

[06:46:17] D: Vertrieb: devuan "4"
---
[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

Running Timeshift v20.11.1

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:

4L3XK commented Feb 2, 2022 •
It seems timeshift need systemd to properly recognize and process a btrfs volume in a LUKS partition.
Booting the system with systemd as init made the btrfs partition available and now snapshotting is working nicely.
The system in use in this issue is MX Linux which uses sysvinit as standard init, hence the problem.

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.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

... may want to consider reaching out to teejee2008  ...

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.

Last edited by Altoid (2023-03-30 22:18:36)

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

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

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

Thanks ...

You're welcome.

... think about starting a small test-system with Debian GNU, luks and btrfs ...

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

... produce some good logfiles and put this to debian-bugs.

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.

... we will see, what happens next. I'll report here.

Right.
Again, thank you very much for this.

Best,

A.

Edit: Devuan spelled wrong ...  B^/

Last edited by Altoid (2023-04-03 20:14:16)

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

Only as an interim result.

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

When I had only the luks + btrfs partition, the btrfs snapshots in timeshift worked very well.
For now I use only rsync method, because btrfs under luks and lvm is not visible in timeshift

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

Last edited by tom (2023-03-31 15:46:12)

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hi,

Devian Chimaera+btrfs + LUKS encryption

Does not work.

Devuan Chimaera+btrfs + no encryption

Is working fine (sysv)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

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

Devuan Chimaera+btrfs + no encryption
Is working fine (sysv)

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.

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hi,

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

Devuan Chimaera+btrfs + no encryption
Is working fine (sysv)

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

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.

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.

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

Last edited by tom (2023-04-03 21:12:10)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

Debian 11+btrfs + LUKS encryption
Does not work.

Debian 11+btrfs + no encryption
Is working fine (sysvinit)

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.

Timeshift is maybe not able to detect a luks partition correctly.

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.

I am trusting LUKS.

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.

tom

Member

Registered: 2022-02-03

Posts: 15  

Re: bug: timeshift doesnt work with LUKS encrypted /

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

Last edited by tom (2023-04-04 01:34:32)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: bug: timeshift doesnt work with LUKS encrypted /

Hello:

Debian 11 (sysvinit) + btrfs + LUKS encryption
Devuan 4 (sysvinit)  + btrfs + LUKS encryption
not working.

OK

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.

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:

4L3XK commented Feb 2, 2022 •
It seems timeshift need systemd to properly recognize and process a btrfs volume in a LUKS partition.

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.