Um...I don't know what to say or do then...
You may not be booted into one on purpose, but you very clearly are booted into one.
Can we get sudo grep subvol /boot/grub/grub.cfg
1 Like
I've always made sure to reboot after confirming restoring any snapshots
linux /restore_backup_@_205307865/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=restore_backup_@_205307865 quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
linux /restore_backup_@_205307865/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=restore_backup_@_205307865 quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
linux /restore_backup_@_205307865/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=restore_backup_@_205307865 quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
So somehow I need to try and overwrite my grub with a previous snapshot and boot into that system instead of a snapshot? I have no clue what has happened to cause this tbh.
sudo sed -i 's/restore_backup_@_205307865/@/g' /boot/grub/grub.cfg
And then give it the old reboot 
2 Likes
Okay I did that thanks. Not sure if it sorted it though as nothing under snapper backups in btrfs assistant though.
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda2[/@] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=656,subvol=/@
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
Looks like I'm not in a snapshot at least though afaik
I'll try my hands at making a script that resets the snapper snapshots, cause this is a mess >.>
Not the first time I've helped someone with this either, so I hope other forum staff will be able to use this then instead of having to call in dalto for this every time 
3 Likes
Thanks that sounds like it could be very useful for others too that run into this. This all stared when an update just died on me partway through unfortunately. I'm trying to work out a manual solution but I can't even remount /dev/sda2 as rw to remove the .snapshots folder in order to try and put restored snapshot in there. Something really has messed up here
Oh, are you not able to write to your root partition right now?
1 Like
Seems so. Here's a sample output from running the command "sudo rm -rf /mnt/@/.snapshots/"
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/debug_map_base.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/priority_queue_base_dispatch.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/standard_policies.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/tree_trace_base.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/type_utils.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/detail/types_traits.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/assoc_container.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/exception.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/hash_policy.hpp': Read-only file system
rm: cannot remove '/mnt/@/.snapshots/369/snapshot/usr/include/c++/11.2.0/ext/pb_ds/list_update_policy.hpp': Read-only file system
Well.... that's never going to work haha
You have to use the btrfs userspace utils to delete subvolumes, you can't use rm
I swear it worked earlier though lol
Well... There's your answer as to why the snapshots don't show up in btrfs-assistant.....
1 Like
Right. So what would you suggest at this point to sort this problem do you think? Really just trying to get snapshots back where they should be and viewable within Btrfs assistant now. No clue what to do at this point.
Do you need them back? My approach would be to delete them and just start over from there.
I'm more than happy to just wipe my snapshots and get new ones. Not sure the best method to nuke and reset this though
We can try the old reliable sudo snapper delete-config && sudo btrfs subvolume list / and see where that gets us.
Deleting config failed (deleting snapshot failed).