edit: here’s what lsblk says my disk layout looks like today (I have an extra 1TB ssd, but otherwise this is what most vanilla manjaro Full Disk Encrtyption installations would look like I’m guessing):
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
nvme0n1 259:0 0 1.8T 0 disk
├─nvme0n1p1 259:1 0 300M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1.8T 0 part
│ └─luks-SOME_REALLY_LONG_HASH_STRING_HERE 254:0 0 1.8T 0 crypt /run/timeshift/backup
└─nvme0n1p3 259:3 0 34.3G 0 part
└─luks-SOME_OTHER_LONG_HASH_STRING_HERE 254:1 0 34.3G 0 crypt [SWAP]
I’m sure this is really a bug in timeshift, but I figure I should post here because I never hit this issue with my non-manjaro installations (like Debian).
Hopefully this helps someone else in the future - it took me a couple hours of searching to hit upon that thread, and it’s only because I was looking for the string in the codebase, so I could start debugging, and I happened upon the closed issue… so there’s no websearch results that surface that very key Github issue … just a bunch of unresolved old forum posts.
also it’s worth noting that Timeshift is apparently non-deterministic in throwing this error. I’ve seen some references to this, and indeed can confirm that I just poked around a bunch of old snapshots and closed/re-opened Timeshift until eventually it went ahead with restore without complaining…
Sooo, some optional conclusions:
a) Timeshift isn’t as great as I’d originally thought
b) Regardless of using timeshift or not (but particularly if you use timeshift): make sure your do more than one practice restore run with your backup strategy of choice, otherwise you might have a really strange non-deterministic behavior like Timeshift’s here.