Greetings!
I tried to install the latest updates (with the pamac gui thingy), the transaction failed, then nothing worked - couldn’t start programs, couldn’t even switch to a tty.
Naturally, I totally forgot to write down the error messages - it was along the lines of “file not found”, I think - and I also panicked and hard reset the PC.
Now it won’t boot, and I can’t even boot from a snapshot (newest snapshot seems to be from 2nd February, which is sus in itself).
“Normal” attempt to boot:
error: file '/timeshift-btrfs/snapshots/$date/@/usr/share/grub/themes/manjaro/...' not found (a bunch of these, actually)
...
error: file '/@/boot/grub/x86_64-efi/bli.mod' not found
error: file '/timeshift-btrfs/snapshots/$date/@/usr/share/grub/themes/manjaro/theme.txt' not found
Selecting a snapshot:
Loading Snapshot: ...
Loading Kernel: ...
error: file '/timeshift-btrfs/snapshots/$date/@/boot/vmlinuz-6.12-x86_64' not found
Loading Microcode & Initramfs: ...
error: you need to load the kernel first
Booted from USB and chrooted into the thing, tried to reapply the update: pacman -Syyu
:: Running pre-transaction hooks...
(1/2) Creating Timeshift snapshot before upgrade...
** (process:4639): CRITICAL **: 19:38:18.190: gee_abstract_collection_get_size: assertion 'self != NULL' failed
E: System disk not found!
Unable to run timeshift-autosnap! Please close Timeshift and try again. Script will now exit...
error: command failed to execute correctly
error: failed to commit transaction (failed to run transaction hooks)
Errors occurred, no packages were upgraded.
update-grub didn’t report any error, but I hope to get some input before attempting to reboot.
How can I fix the failed transaction when trying to update packages?
Apparently it’s timeshift-autosnap-manjaro… but pacman -Syyu worked after removing it. Thanks!
I dared to reboot, and it looks like the system works.
However, something else strange is going on: I edited /etc/fstab recently (like, last week), and those changes are gone. I can’t even find them in any of the daily snapshots. Have I (or the PC) been transfered to a different timeline? Is there a chance to find the edited file anywhere else? (Yes I know about the concept of backups )
More seriously: how do I continue to investigate, and fix, why timeshift-autosnap doesn’t work when trying to update?
Huh. But… where? How? It was a fresh boot from USB. Unless it has a lock file somewhere.
Oh by the way, when the system failed to boot, I got offered snapshots from January and February 2nd. Now the snapshots displayed in timeshift are actually from February 2nd up until today. There is even a snapshot from around the time I first tried today’s update! Or, well, maybe, as at least one of the files ist old in the snapshot, as far as I can tell…
It may have a lock file — I do not know. I only ever run timeshift manually, and I’ve never investigated how it works.
That is odd. Maybe there was a failed snapshot in there that didn’t get deleted, or maybe your system clock was off.
Yes, but that will be a faulty one, if the error message was correct.
It is possible. But I don’t have any experience with btrfs snapshots — that would be pointless with my setup. I use rsync-based snapshots — i.e. actual backups, on a spinning HDD — instead.
I would think that, if the snapshots don’t appear in Timeshift, that they don’t exist - yet apparently they do. Do snapshots contain older snapshots and somehow an older snapshot was selected upon the failed boot?
No, the one thing that I’ve discovered is that an interrupted timeshiftsnapshot won’t show up in timeshift itself, but its files will still be on the drive.
In other words, timeshift does not clean up after itself when it fails. And I reckon that’s what you may be looking at now.
In the future, you can disable the pacman hook by editing:
/etc/timeshift-autosnap.conf
And change
skipAutosnap=false
to true
But uninstalling works too.
Unfortunately, you can’t run Timeshift from a live image boot.
But you can run Timeshift from a grub-btrfs snapshot boot.
(Unfortunately, yours are broken.)
Not so fast. I have restored btrfs snapshots manually many times if they are there. It’s not a 1-click restore, but all you really need is a root (maybe plus @home) snapshot to bring everything back.
timeshift-autosnap.conf has a (near useless for rolling back) default of maxSnapshots=3. This only gives you one usable rollback snapshot, since it creates one when you restore. So you can’t even restore a second time or try a different snapshot.
But that’s not even working.
Which is good, if you want an older snapshot still..
Not like that. But you can snapshot any snapshot, so kind of? But I don’t see how this could happen if I understand you.
It sounds like something got really messed up with subvolumes and/or grub.
To give us an idea what is going on, what is the output of:
It never worked when I tried. (CLI were the same errors, no reason timeshift-gtk wouldn’t work if the command-line version did) But that was a couple years ago. I should probably give it another go.
I imagine it would be the same, it does not give you much in configurability with many things. I don’t think it picks up the root device properly booting into the overlayfs, and it was hardcoded into the binary.
If you have your snapshots, you can mount any of them and look inside.(if you are root). If the older snapshots are truly gone, then Timeshift has deleted them.
mount -t btrfs
shows you, what options to use, and what device is used for /
Then
my options: rw,noatime,compress=zstd:7,
my snapshot: subvol=timeshift-btrfs/snapshots/2026-02-12_18-26-33/@
my device: /dev/nvme0n1p3
my mountpoint: /mnt
mount -o rw,noatime,compress=zstd:7,subvol=timeshift-btrfs/snapshots/2026-02-12_18-26-33/@ /dev/nvme0n1p3
After that you can copy/inspect any of the files that reside there (/mnt) to your actual system.
Do not change any files inside a timeshift-snapshot !!!
P.S. For several good reasons, I use Snapper instead of Timeshift. While it doesn’t have a pretty GUI, it works reliably and adheres to the specifications of the btrfs developers.