ID 256 gen 36056 top level 5 path restore_backup_@_205307865
ID 257 gen 36084 top level 5 path @home
ID 258 gen 36065 top level 5 path @root
ID 259 gen 35265 top level 5 path @srv
ID 260 gen 36078 top level 5 path @cache
ID 261 gen 36084 top level 5 path @log
ID 262 gen 36050 top level 5 path @tmp
ID 263 gen 35115 top level 656 path .snapshots
ID 408 gen 35829 top level 5 path restore_backup_@_224657520
ID 493 gen 35829 top level 5 path restore_backup_@_231252474
ID 500 gen 36015 top level 5 path restore_backup_@_040118184
ID 519 gen 36015 top level 5 path restore_backup_@_050533893
ID 544 gen 36015 top level 5 path restore_backup_@_051747333
ID 615 gen 36015 top level 5 path restore_backup_@_052135433
ID 616 gen 36015 top level 5 path restore_backup_@_052311921
ID 617 gen 36015 top level 5 path restore_backup_@_054028336
ID 626 gen 36015 top level 5 path restore_backup_@_233800042
ID 641 gen 36015 top level 263 path .snapshots/369/snapshot
ID 642 gen 36015 top level 263 path .snapshots/370/snapshot
ID 643 gen 36015 top level 263 path .snapshots/371/snapshot
ID 644 gen 36015 top level 263 path .snapshots/372/snapshot
ID 645 gen 36015 top level 263 path .snapshots/373/snapshot
ID 646 gen 36015 top level 263 path .snapshots/374/snapshot
ID 647 gen 36015 top level 263 path .snapshots/375/snapshot
ID 648 gen 36015 top level 263 path .snapshots/376/snapshot
ID 649 gen 36015 top level 263 path .snapshots/377/snapshot
ID 650 gen 36015 top level 263 path .snapshots/378/snapshot
ID 651 gen 36015 top level 263 path .snapshots/379/snapshot
ID 652 gen 36015 top level 263 path .snapshots/380/snapshot
ID 653 gen 36015 top level 5 path restore_backup_@_233951712
ID 654 gen 36015 top level 5 path restore_backup_@_234118553
ID 655 gen 36015 top level 5 path restore_backup_restore_backup_@_234140482_005828109
ID 656 gen 36084 top level 5 path @
ID 657 gen 36056 top level 5 path restore_backup_@_234140482
Yeah that's what I thought.
sudo btrfs subvolume delete -i {641..652} / && sudo btrfs subvolume list /
ERROR: {641..652} is not a valid numeric value.
Yeah, don't run that in fish, run it in bash. Sorry I didn't specify.
Oh right, yeah I tried that when fish failed but got a different error.
btrfs subvolume delete: exactly 1 argument expected, 12 given
Ohmygodiwannadie
for i in {641..652}; do sudo btrfs subvolume delete -i $i /; done
2 Likes
Haha, sameâŚanyway that worked it seems thanks
Delete subvolume (no-commit): '//@/.snapshots/369/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/370/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/371/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/372/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/373/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/374/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/375/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/376/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/377/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/378/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/379/snapshot'
Delete subvolume (no-commit): '//@/.snapshots/380/snapshot'
ID 256 gen 36056 top level 5 path restore_backup_@_205307865
ID 257 gen 36106 top level 5 path @home
ID 258 gen 36065 top level 5 path @root
ID 259 gen 35265 top level 5 path @srv
ID 260 gen 36098 top level 5 path @cache
ID 261 gen 36106 top level 5 path @log
ID 262 gen 36050 top level 5 path @tmp
ID 263 gen 36105 top level 656 path .snapshots
ID 408 gen 35829 top level 5 path restore_backup_@_224657520
ID 493 gen 35829 top level 5 path restore_backup_@_231252474
ID 500 gen 36015 top level 5 path restore_backup_@_040118184
ID 519 gen 36015 top level 5 path restore_backup_@_050533893
ID 544 gen 36015 top level 5 path restore_backup_@_051747333
ID 615 gen 36015 top level 5 path restore_backup_@_052135433
ID 616 gen 36015 top level 5 path restore_backup_@_052311921
ID 617 gen 36015 top level 5 path restore_backup_@_054028336
ID 626 gen 36015 top level 5 path restore_backup_@_233800042
ID 653 gen 36015 top level 5 path restore_backup_@_233951712
ID 654 gen 36015 top level 5 path restore_backup_@_234118553
ID 655 gen 36015 top level 5 path restore_backup_restore_backup_@_234140482_005828109
ID 656 gen 36105 top level 5 path @
ID 657 gen 36056 top level 5 path restore_backup_@_234140482
Now go ahead and do: sudo rm -r /.snapshots/* && for i in {256,408,493,500,519,544,615,616,617,626,653,654,655,657}; do sudo btrfs subvolume delete -i $i /; done && sudo btrfs subvolume list /
Damn that was a long command. I really appreciate you taking the time to type that out and help haha.
Delete subvolume (no-commit): '//restore_backup_@_205307865'
Delete subvolume (no-commit): '//restore_backup_@_224657520'
Delete subvolume (no-commit): '//restore_backup_@_231252474'
Delete subvolume (no-commit): '//restore_backup_@_040118184'
Delete subvolume (no-commit): '//restore_backup_@_050533893'
Delete subvolume (no-commit): '//restore_backup_@_051747333'
Delete subvolume (no-commit): '//restore_backup_@_052135433'
Delete subvolume (no-commit): '//restore_backup_@_052311921'
Delete subvolume (no-commit): '//restore_backup_@_054028336'
Delete subvolume (no-commit): '//restore_backup_@_233800042'
Delete subvolume (no-commit): '//restore_backup_@_233951712'
Delete subvolume (no-commit): '//restore_backup_@_234118553'
Delete subvolume (no-commit): '//restore_backup_restore_backup_@_234140482_005828109'
Delete subvolume (no-commit): '//restore_backup_@_234140482'
ID 257 gen 36119 top level 5 path @home
ID 258 gen 36065 top level 5 path @root
ID 259 gen 35265 top level 5 path @srv
ID 260 gen 36107 top level 5 path @cache
ID 261 gen 36119 top level 5 path @log
ID 262 gen 36050 top level 5 path @tmp
ID 263 gen 36105 top level 656 path .snapshots
ID 656 gen 36118 top level 5 path @
That should be all! Enjoy!
Fantastic.
I'll bookmark this topic as btrfs housekeeping 
1 Like
Thank you! Seems like I can create snapshots again. Problem is that I'm in grub rescue mode now though after a reboot. I'll try a chroot to reinstall grub
Yeah this is the place to go if something weird happens with snapper haha. Thanks for your help too btw
1 Like
Well my hope is you won't have to and will just be able to do update remote fix-snapper in the future 
Also hey hey >.>
5 Likes
Okay everything fixed finally haha. Got all my snapshots there like they should be and fixed grub which was still overwritten from a resorted backup apparently. I really hope that in the future something can be added to the Garuda assistant to do all these commands I ran. Like if the normal doesn't work then some kind of snapper fix GUI that may go through a couple of stages. Like if this command fails then try the next etc like you had me to with the first command which failed. Would be a useful addition I feel. Anyway thanks again!
2 Likes
I restored a snapshot and had the same issue happen to me (booo!!!)
ID 257 gen 384944 top level 5 path @home
ID 258 gen 384943 top level 5 path @root
ID 259 gen 362852 top level 5 path @srv
ID 260 gen 384943 top level 5 path @cache
ID 261 gen 384944 top level 5 path @log
ID 262 gen 384943 top level 5 path @tmp
ID 2110 gen 384934 top level 5 path restore_backup_@_221503196
ID 2196 gen 384936 top level 2110 path restore_backup_@_221503196/.snapshots
ID 2197 gen 384909 top level 2196 path restore_backup_@_221503196/.snapshots/1/snapshot
ID 2198 gen 384910 top level 2196 path restore_backup_@_221503196/.snapshots/2/snapshot
ID 2199 gen 384911 top level 2196 path restore_backup_@_221503196/.snapshots/3/snapshot
ID 2200 gen 384912 top level 2196 path restore_backup_@_221503196/.snapshots/4/snapshot
ID 2201 gen 384913 top level 2196 path restore_backup_@_221503196/.snapshots/5/snapshot
ID 2202 gen 384937 top level 2196 path restore_backup_@_221503196/.snapshots/6/snapshot
ID 2203 gen 384915 top level 2196 path restore_backup_@_221503196/.snapshots/7/snapshot
ID 2204 gen 384916 top level 2196 path restore_backup_@_221503196/.snapshots/8/snapshot
ID 2205 gen 384917 top level 2196 path restore_backup_@_221503196/.snapshots/9/snapshot
ID 2206 gen 384918 top level 2196 path restore_backup_@_221503196/.snapshots/10/snapshot
ID 2207 gen 384919 top level 2196 path restore_backup_@_221503196/.snapshots/11/snapshot
ID 2208 gen 384920 top level 2196 path restore_backup_@_221503196/.snapshots/12/snapshot
ID 2209 gen 384921 top level 2196 path restore_backup_@_221503196/.snapshots/13/snapshot
ID 2210 gen 384922 top level 2196 path restore_backup_@_221503196/.snapshots/14/snapshot
ID 2211 gen 384923 top level 2196 path restore_backup_@_221503196/.snapshots/15/snapshot
ID 2212 gen 384924 top level 2196 path restore_backup_@_221503196/.snapshots/16/snapshot
ID 2213 gen 384925 top level 2196 path restore_backup_@_221503196/.snapshots/17/snapshot
ID 2214 gen 384926 top level 2196 path restore_backup_@_221503196/.snapshots/18/snapshot
ID 2215 gen 384944 top level 5 path @
After using my reset script, however, this has all been fixed:
ID 257 gen 384948 top level 5 path @home
ID 258 gen 384948 top level 5 path @root
ID 259 gen 362852 top level 5 path @srv
ID 260 gen 384943 top level 5 path @cache
ID 261 gen 384948 top level 5 path @log
ID 262 gen 384943 top level 5 path @tmp
ID 2215 gen 384948 top level 5 path @
ID 2216 gen 384948 top level 2215 path .snapshots
So for any helpers or users stumbling across this in the future, update remote reset-snapper is the magic command!
@dalto I would appreciate if you could double check the code for me, but I ran it on my own machine a couple billion times and didn't notice anything going wrong so fingers crossed? 
https://gitlab.com/garuda-linux/themes-and-settings/settings/garuda-common-settings/-/snippets/2147440/raw/main/reset-snapper
7 Likes
Oh wow you ran into this too? I wonder what causes this to happen sometimes then as it got me and you today. I don't assume it's a bug introduced in snapper recently would it or is it just a coincidence we both had this problem? And I'd that code is all good then maybe consider adding it to the Garuda assistant for other users so they don't have to go searching for commands like this? Just a thought, thanks for the script though I'll be keeping this close haha
This is an interesting one, several people have reported this but I have never been able to reproduce it and I have done a lot of test restores.
That being said the code in btrfs-assistant-git is totally different so I probably wonât worry about it much unless it persists after that is released.
The biggest issue I see after a quick look is that if someone has any nested subvolumes other than .snapshots they are going to get deleted along with all their snapshots.
1 Like
I see the script checks for if a user is booted into a snapshot and if it does then it echoes that to the user letting them know. But then it simply exits the script? Or did I read it wrong? So if a user like I was, is booted into a snapshot and a reboot doesn't fix it then would I manually need to find that command to fix the snapshot booting or does your script handle that?
Yeah, using the native Qt API more is definitely a major plus.
I am just going to politely ignore this as an impossibility
You canât possibly have subvolumes that didnât successfully get migrated, right? It canât possibly happen!
Yes, the former. Adding code for such an edge case just isnât worth my time.
Pssst @dalto I suggest you replace btrfs-assistant.cpp ¡ c0e8d89c517e31815b95e6447a4dbd8d635c5ff4 ¡ Garuda Linux đŚ / Applications / BTRFS Assistant ¡ GitLab with
QString output = runCmd("btrfs subvolume list / | awk -v id=" + subvolid + " '{if (id == $7) {print $7, $9}}'", false).output;
The way you use grep there is, uh, quite flawed and quite pointless. You can also get rid of all the splitting logic by just exclusively printing $9 since you donât need $7 for the grep anymore.
I love you awk <3
1 Like