I followed the wonderful guide written by @2000 found here:
All was moving swimmingly until I tried to install zoom and it caused a crash. At first, I would get to the sddm login and once I input my password I would get a system freeze.
I tried booting into my grub snapshots. I selected one, and now the system won’t boot to sddm. It stalls after the grub image/snapshot selector where it typically should boot to sddm.
I got my liveiso to boot from and I think I figured out why I’m having the issue where the snapshot isn’t booting. After installing timeshift gui and browsing through the snapshots folder, I find that there are indeed snapshot directories in the main directory, but timeshift doesn’t recognize any of the snapshot directories as snapshots; that is to say there are snapshot directories, full with snapshots, however, for whatever reason, timeshift doesn’t recognize the snapshot in a way where it will use to restore. Instead, all that is said on the GUI and CLI is “no snapshots found”, despite the directory being full with snapshots.
Could someone suggest a fix to turn these snapshot directories into actual snapshots I can use?
Thanks for the quick reply. To date, this is my favorite distro, so I’m glad to be part of the community.
Is there any way to diagnose what might be wrong with a given volume? I know it’s fairly technically high level, but is there a way to repartition or replace the volume data to correct the error? Or is the better option just to do a reinstall?
You could try to restore a snapshot manually.
By following your steps, would I be doing what I suggested above, or is that just a suggestion on how to manually restore a snapshot?
Sure, but given the amount of possibilities and the fact that you may have functioning snapshots I personally think this question is purely academic.
If your btrfs filesystem contains a @ subvolume, why don’t you rename it to e. g. @_checklater and restore a working snapshot by renaming (per mv command for instance) it to @ first. You could then run all sort of checks on the subvolume @_checklater later on.
Both! Assuming the error isn’t hardware related (failing storage etc.), replacing/generating a @ subvolume with a functioning snapshot subvolume does exactly that; it “replaces the volume data to correct the error”. If all goes well there’s no need to repartition or reinstall anything.