So i have move /snap to another disk because it was starting to take up too much space (don’t feel upset I did the same with flatpaks as well) however snap throw a wobbly and drops me into an emergency shell stopping the boot process if it start before the /snap mount is active. If I then manually mount it and continue the boot everything is fine. I have arranged the fstab order to put it just after boot but that did not help. So now I have had to resort to tweaking snapd.service file to force it to wait until the mount is complete.
So I don’t think I am the only one who wants to keep ./snap on a different disk so can we make it fail more gracefully when that disk is not mounted?
Indeed it looks like some content was unpacked into /snap by hand. snapd itself does not do that. Any normal system should look like what @chipaca describes above.
If you did not do that yourself, I’m quite curious to hear which tool did that.
Again, snapd never copies content into those directories as displayed above. There’s just no code doing that, anywhere. These are mountpoints only.
Given your original question:
Was that move done by recursively copying all the contents? That would indeed create the situation described above, and probably make snapd unhappy about working with those directories because they are supposed to be mountpoints, not trees of files.
Was that move done by recursively copying all the contents?
It was literally an rsync -av --partial --progress /snap .
and if if they were just symlinks then remove /snap should not have freed up 5+Gb of space should it? But it did. Furthermore installing new packages should have symlinks in my mounted /snap.
ls -la /snap
lrwxrwxrwx 1 root root 21 Oct 29 13:03 /snap -> /mnt/containers/snap/
ls -la /snap/
total 0
drwxr-xr-x 14 root root 229 Nov 13 16:15 .
drwxr-xr-x 4 root root 127 Nov 5 23:05 …
drwxr-xr-x 2 root root 221 Nov 13 16:15 bin
drwxr-xr-x 4 root root 41 Oct 28 17:01 castersoundboard
drwxr-xr-x 5 root root 57 Oct 28 17:03 core
drwxr-xr-x 3 root root 31 Sep 13 11:30 doctl
drwxr-xr-x 5 root root 51 Oct 10 12:04 krita
drwxr-xr-x 3 root root 31 Sep 6 13:48 lonewolf
drwxr-xr-x 3 root root 32 Sep 15 15:59 magic-device-tool
drwxr-xr-x 3 root root 30 Oct 10 23:04 pulsemixer
drwxr-xr-x 4 root root 43 Nov 13 16:13 snapweb
drwxr-xr-x 4 root root 39 Oct 3 10:07 teleconsole
drwxr-xr-x 3 root root 30 Oct 18 13:00 uappexplorer-cli
drwxr-xr-x 3 root root 30 Sep 24 16:23 ultimate-media-downloader
I just refreshed snapweb to the edge channel because it was showing up as broken in the stable version.
Well, if you ever find out who created those files in your filesystem please let us know. It wasn’t snapd for sure.
I suggest immediately undoing all of that by deleting all the content in /snap, creating the directory empty again in the root filesystem, and reinstalling the respective snaps. Or just remove the snapd package and reinstall it, making sure you have no /snap after removing the package, because snapd will not kill the content it doesn’t own there.
Then have a look at the result. It will look like the situation @chipaca described: symlinks and mountpoints only.
Note that if you are low on space and have an internal (mounted a boot) disk you can just mount a partition on /var/lib/snapd/snaps and copy the snaps over. This is where the space is really used.
Note that if you are low on space and have an internal (mounted a boot) disk you can just mount a partition on /var/lib/snapd/snaps and copy the snaps over. This is where the space is really used.
If you did that command on that target disk (/mnt/containers/snap/) then you definitely doubled up (likely even more because the target will have the data uncompressed) the space your snaps use by copying the content of the mounted compressed squashfs’es out of the mountpoints into the target disk …
Ok I guess I have had enough of this. I will blow away snapd completely and start again. This time looking for where it puts actual snaps and where is looback mounts them. Because I swear it was freeing up space by removing /snap
@veritanuda you have copied the contents of snap files to another disk. Not the snaps themselves. This won’t end well.
The disk space consumed by snaps is all in /var/lib/snapd/snaps, not /snaps
alan@hal:~$ du -hs /var/lib/snapd/snaps
16G /var/lib/snapd/snaps
When you ‘snap install’ something, you get a .snap file in /var/lib/snapd/snaps/ - e.g. for teleconsole I have
alan@hal:~$ ls -l /var/lib/snapd/snaps/teleconsole_3.snap
-rw-r--r-- 1 root root 3661824 Oct 3 04:04 /var/lib/snapd/snaps/teleconsole_3.snap
That is the only disk space the snap takes up. That compressed file is mounted (not unpacked) in /snap/teleconsole/ and a symlink at /snap/teleconsole/current points to that
alan@hal:~$ mount | grep teleconsole
/var/lib/snapd/snaps/teleconsole_3.snap on /snap/teleconsole/3 type squashfs (ro,nodev,relatime)
alan@hal:~$ ls -l /snap/teleconsole/current
lrwxrwxrwx 1 root root 1 Oct 3 04:04 /snap/teleconsole/current -> 3
At runtime, yes, you will see files in /snap/teleconsole/3
alan@hal:~$ du -hs /snap/teleconsole/3/
15M /snap/teleconsole/3/
However, if you shut the machine down, and examine the disk, you’ll see nothing in /snap, because they only get mounted when the system is started.
So what you’ve done is copy files from the insides of those .snap files to an external/separate disk. The snaps which get updated in /var/lib/snapd/snaps will have new and updated files which you will not have in your copies. You’ve basically broken the snap installs.
Yeah well I purged snapd now, made symlink from /var/lib/snapd/snaps -> /mnt/containers/snap and am installing warsone2100 now see where it all ends up. If as you say all the magic is in /var/lib/snapd/snaps then it should not take up any more space on root but on the /mnt/containers/snap instead. In which case my snapd.mount services is still needed to stop snapd from breaking boot but it just points to a different symlink then.
