I noticed some old snapshots lying around for the root config from when I was hit with a ext4-btrfs conversion bug and I had a half-working btrfs partition. I proceeded to delete them, but snapper refused to comply:
# snapper -c root delete 274
Config is in use.
Cleanup also failed
# snapper -c root cleanup number
Config is in use.
Now I’m stuck with a lot of old snapshots and only a few GBs of free space. How can I delete these old snapshots?
Yes, at some point I booted from a snapshot - my partition was unstable due to buggy ext4 -> btrfs conversion code. I managed to fix it eventually but I needed a custom build of btrfsprogs and a lot of help from snapper to find a right solution ( looking at the snapshots it happened at some point in July ).
btrfs sub get-default /
ID 1492 gen 92362 top level 493 path .snapshots/359/snapshot
Unfortunately, I haven’t found a way to specify a range of snapshots, I’ve only been able to specify each and every snapshot one by one although all can be done in a single command as I described.
This fails for all snapshots that I’ve tested for in the root config.
Superfluous? Yes Incorrect? No
The -c argument specifies the snapper config to use ( defaulting to root ) , see the snapper man page.
Thanks, but that’s not my issue. I an unable to delete any snapshot for the root config. I would be happy if snapper cleanup would work, it should remove a lot of old snapshots, but at the moment it can’t remove any.
AFAIK, specifying a config is not the same as actually switching to that User.
The error you’re seeing is entirely accurate but I think you’re mis-interpreting… In other words…
Snapper trying to use a default config which is called “root.” Can’t switch to a config called “root” because it already exists and is currently being used.
I’d be surprised if you followed the steps I described exactly and you still have a problem.
So, for example
su to root. The result should be a root console
su
Next, type the following exactly or paste (CTL-SHFT-V in a Bash terminal)
snapper delete 274
Or, try deleting a few snapshots in your list with obviously low priority
snapper delete 323 324 358 359
You can verify your results by listing your snapshots again
snapper list
Have done the above many times on a number of systems without ever a problem.
Thanks for the detailed instructions, see my exact terminal output beloe
$ su
Password:
mars:/home/robert # id
uid=0(root) gid=0(root) groups=0(root)
mars:/home/robert # snapper delete 274
Config is in use.
mars:/home/robert # snapper delete 323 324 358 359
Config is in use.
I am sure of that But something in my snapper config/setup is broken, and I’m not sure exactly what and how to fix it.
To me, that output looks like a vestige of your previous incorrect command is still in use.
Am almost certain your misconfiguration is only related to the console session, either close/open a new console and “su” again or reboot and everything should be cleared and returned to default.
Can you remove any snapshot created after this one (so far all your examples show earlier snapshots)?
And, BTW, you always can remove btrfs snapshots directly; I thought there was some snapper option to cross-check, but I do not see one. You will be able to manually clean up by removing dangling snapshot directories under /.snapshots though. But it would be helpful to find root cause for your problem first.
Well, after a reboot I was suddenly able to remove snapshots … both with -c root and without it. I was able to delete all ‘old’ snapshots except one (thanks to both for helping!), but one snapshot refuses to go:
# snapper delete 359
Deleting snapshot failed.
Snapper log shows a BTRFS error:
2016-03-06 10:36:57 MIL libsnapper(11762) Snapper.cc(Snapper):103 - subvolume:/ filesystem:btrfs
2016-03-06 10:36:57 MIL libsnapper(11762) Snapper.cc(loadIgnorePatterns):152 - number of ignore patterns:8
2016-03-06 10:36:57 ERR libsnapper(11762) Snapshot.cc(read):217 - loading 357 failed
2016-03-06 10:36:57 ERR libsnapper(11762) Snapshot.cc(read):217 - loading 393 failed
2016-03-06 10:36:57 ERR libsnapper(11762) Snapshot.cc(read):217 - loading 430 failed
2016-03-06 10:36:57 MIL libsnapper(11762) Snapshot.cc(read):223 - found 72 snapshots
2016-03-06 10:36:57 ERR libsnapper(11762) Snapshot.cc(check):276 - time shift detected at snapshot num 1224
2016-03-06 10:36:57 ERR libsnapper(11762) Btrfs.cc(deleteSnapshot):375 - delete snapshot failed, ioctl(BTRFS_IOC_SNAP_DESTROY) failed, errno:1 (Operation not permitted)
2016-03-06 10:36:57 WAR libsnapper(11762) Client.cc(dispatch):1518 - CAUGHT: delete snapshot failed
The btrfs mount seems fine, I scrubbed it immediately afterwards:
# /etc/cron.monthly/btrfs-scrub.sh
Running scrub on /
scrub device /dev/sda1 (id 1) done
scrub started at Sun Mar 6 10:43:29 2016 and finished after 00:08:40
total bytes scrubbed: 186.21GiB with 0 errors
Does this have any ill side-effects, like preventing free space from being reclaimed since the blocks used in that snapshot will always be around? Should I alter the setup somehow?
the system is installed into a (read/write) snapshot.
If you look at newly installed system, your real root is actually /.snapshots/1/snapshot subvolume. When you restore from snapshot, you flip root to another snapshot; it does not change anything w.r.t. space consumption. I wonder whether it may confuse snapper though (as newer snapshots now have “older” numbers).
So we still do not know what caused your issue. Pity.
Whenever you do a rollback, you don’t actually revert to the earlier snapshot id. That earlier id is only used to reference the time/date when that snapshot was created. You can think of these snapshots as virtual indexing numbers only to identify and not the actual snapshots themselves.
When you do a rollback, a new snapshot with a new id is created, so even when rolling back you’re always moving forward numerically. the BTRFS snapshot functionality is supposed to track these changes automatically and resolve all snapshot incremental relationships like deleting, so as long as you use a BTRFS authorized tool like snapper everything should work without a problem.
Well, it happened again ( not sure if it’s related to suspend, I tend to do that quite a lot on my desktop ). The only entry in in /var/log/snapper.log is
2016-03-09 21:45:40 WAR libsnapper(21360) Client.cc(dispatch):1488 - CAUGHT: config in use
Incorrect? No