This should be covered by snapshots already. When you remove a snap with snap remove foo it automatically creates a snapshot of snap data found under /var/snap and under users’ homes. (not to be confused with snap remove --purge which does not save a snapshot).
maciek@galeon:~ snap saved
Set Snap Age Version Rev Size Notes
312 test-snapd-zfsutils 13.8d 2.2.2 x1 253B auto
maciek@galeon:~ snap remove wormhole
wormhole removed
maciek@galeon:~ snap saved
Set Snap Age Version Rev Size Notes
312 test-snapd-zfsutils 13.8d 2.2.2 x1 253B auto
313 wormhole 2.32s 0.16.0+2.g1bd72f3 509 324B auto
where the content of the snapshot for wormhole is:
galeon# unzip -l 313_wormhole_0.16.0+2.g1bd72f3_509.zip
Archive: 313_wormhole_0.16.0+2.g1bd72f3_509.zip
Length Date Time Name
--------- ---------- ----- ----
125 1980-00-00 00:00 archive.tgz
199 1980-00-00 00:00 user/maciek.tgz
467 1980-00-00 00:00 meta.json
97 1980-00-00 00:00 meta.sha3_384
--------- -------
888 4 files
Perhaps it’d be useful to show a short info that the data has been archived and can be restored or they can then use Snapshots | Snapcraft documentation to export and inspect it. I’ve filed Bug #2114704 “indicate that snapshot was created during snap rem...” : Bugs : snapd
I was using the VS Code snap, and realised that uv tool list wouldn’t show any of my installed tools, plus uv tool install would install them in some “weird” directory that was not in the $PATH.
I then proceeded to sudo snap remove code and getting this error:
error: cannot perform the following tasks:
- Save data of snap "code" in automatic snapshot set #3 (cannot create archive:
tar: 198/.local/share/containers/storage/overlay/cf4bbf00f26d594989e57afbbfabb2ce635cf38a349ec586c347fac367126410/diff/var/lib/apt/lists/partial: Cannot open: Permission denied
tar: 198/.local/share/containers/storage/overlay/cf4bbf00f26d594989e57afbbfabb2ce635cf38a349ec586c347fac367126410/diff/var/cache/apt/archives/partial: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors)
This is with a 2-days old, freshly installed Linux Mint… I haven’t had time to screw up my system so badly yet!
Thanks for posting, though I think your issue is outside of the scope of what I’m trying to achieve here.
In any case, having a quick look at the logs, it seems that inside “code” per-snap-revision data directory you have some additional unexpected data, likely owned by podman/docker. In any case, the permissions or ownership of those files is likely an issue. When you remove a snap, by default, snapd attempts to take a snapshot of the snap’s data such that you’re later able to recover/export it, but if the data is not accessible for root (like it is in your case), creating snapshot will fail. Try snap remove --purge code, which will simply remove the snap’s data, without trying to save a snapshot.
it’s perhaps worth trying to figure out why you even have this data there? It feels wasteful to not use a dedicated, shared between revisions, snap data directory. Then again, snapd can’t really do anything about questionable packaging.
2 Likes
Played with a couple of variants, a single snap installation (ohmygiraffe, which pulls in gnome runtime):
https://asciinema.org/a/urVbYfMhFLm3o34Dz2zivz28v
and then a multi snap installation (ohmygiraffe + firefox + dependencies):
https://asciinema.org/a/zR0jmK2i2ycca7bPVxXTii4tM
I feels a bit better, in the sense that one can see that something is going on, but at the same time one could argue it feels a jumpy?
1 Like
The first example looks brilliant; I agree the second is a bit jumpy, but it’s still better than the current version because it’s directly showing what the bottleneck actually is and it’s rewriting the same line rather than spamming the output so even though it’s jumpy, it’s not noisy.
You’re downloading the Gnome content snap in the second version at 35MB or 280Mbit per second (That’s ignoring the Firefox snap which peaks at nearly a gigabit per second too!), that’s a top end speed where we might find people in rural areas operating at 1% if not lower than that, so even with it being a bit jumpy, it’s clearly demonstrating stuff is happening, it’s just slow; rather than the current approach where you see “automatically connecting plugs” potentially 5 minutes sometimes but 10 seconds other times, when the actual interface connections are only seconds; a user not seeing the other downloads could just hit control-c thinking it’s crashed.
Perfect is the enemy of good enough, and that to me looks perfect for one and good enough in the other. 
1 Like
