Oh I completely get it, NOW anyway. My sleep deprivation and work wasn’t helping me deal with this. But anyone that is very familiar with Linux, but not Timeshift and btrfs (like me) would not get this, at first anyway.
That “Restore” button does NOT do what you would expect it would. Even with me dealing with ZFS for 25ish years, and other snapshoting filesystems, NetApp and other enterprise HD arrays, etc etc.
Just for anyone else that will most likely run into this issue I had, and is still reading this…
Just testing and playing around with this more, I realised that there’s a lot more references to that snapshot in grub.cfg. So when that snapshot is deleted or cleaned up automatically, there would be even more problems.
grep 2022-10-15_23-44-29 /boot/grub/grub.cfg | wc
22 64 2958
That’s 22 lines with references to the old snapshot. (And some lines have multiple references.)
So a lot more needs to be modified to completely fix it. The majority are loading fonts, and the theme, which probably wouldn’t an issue. (No idea actually.) But there are some important ones like your fallback kernel, and every other sub-menu boot item.
So I’m just deleting every reference to /timeshift-btrfs/snapshots/2022-10-15_23-44-29 in my case, and it should be left with a /@/... trailing what is removed.
For example this line:
loadfont ($root)/timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/usr/share/grub/themes/manjaro/dejavu_sans_12.pf2
Becomes:
loadfont ($root)/@/usr/share/grub/themes/manjaro/dejavu_sans_12.pf2
And the same edits for the fallback kernel, which has to be done again for linux and linuxrd, and the memtest, etc.
I thought update-grub would correctly overwrite this grub.cfg if your system is running right in the root subvolume @. You do not need to edit it manually.
I wrote above:
ZFS restoring is different than Btrfs restoring.
I see there is a risk, if ZFS instantly restores any snapshot to your system while your system and multiple processes are still running, your system or processes would be broken e.g. they read/write inconsistent data after restoring the snapshot without reboot. But you have to turn off the system and processes first then restore ZFS snapshot.
Btrfs restoring does not break your system while your system is running, but you need to reboot for the restoring to take effect.
ZFS restores a previous/old snapshot and must delete its all subsequent/new snapshots, unlike Btrfs that does not delete any snapshots when restoring. AFAIK, Btrfs snapshots are more flexible than ZFS snapshots because of B-Tree.
A big advantage is that Btrfs lets you switch any different snapshots like git branches.
ZFS snapshots are like Git commits.
BTRFS snapshots are like Git branches.
GRUB will overwrite the grub.cfg that it sees (that is mounted under /boot/grub)
This grub.cfg may be in a different partition, or it may be within the same partition, the snapshot is running from.
If grub.cfg is in the same partition as the snapshot, it would be automagically restored to the right state.
If grub.cfg lies outside the snapshot, it needs to be rewritten. (after mounting /boot/grub to the right place)
This grub.cfg is in /boot/grub/ in the same partition of Btrfs filesystem, see:
Only /boot/efi is for the other partition FAT32.
I’m pretty sure I did that. For much of this, I was going off of pretty much no sleep. I could be mistaken.
ZFS was also created roughly two decades ago. 
I did a lot of work with SunOS/Solaris back then.
Anyway, at least it’s all back to normal now.
So now my next steps… Ripping out Timeshift and using Snapper! And most likely redoing my RAID 1 volume to brtfs so I can btrfs send my snapshots to for backups. I actually haven’t researched it a lot yet. But that’s for another day and topic.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.