How to handle unused loop partition after removing snap/snapd?

Question

While working on an Ubuntu Server for personal use, I removed what would not be necessary for my usage. It is snapd & snap that I would like to properly clean.

I removed snap and snapd using the neatest way possible (snap remove <the default installed snap:core,lxd,snapd> + apt remove --purge snap). It indeed remove the daemond, the cache,the /snap folder however but it doesn't clean the loop parititon, it's unmounted for the moment.

There is a mention of an additional cleanning command I should have run before uninstall all but it's too late. Command would have been snap remove --purge <installed snap:core,lxd,snapd>, mention here.

How can I remove those loop partition in the best way possible ?
Would it be hard to re install snap latter ? (if needed)

See result of lsblk :

>$lsblk -a
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0                       7:0    0     0B  1 loop
loop1                       7:1    0     0B  1 loop
loop2                       7:2    0     0B  1 loop
loop3                       7:3    0     0B  1 loop
loop4                       7:4    0     0B  1 loop
loop5                       7:5    0     0B  1 loop
loop6                       7:6    0     0B  0 loop
loop7                       7:7    0     0B  0 loop
sda                         8:0    0 279.4G  0 disk
├─sda1                      8:1    0     1M  0 part
[...]

the used distrib bellow

>$uname -a
Linux ubuntu 5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Update I

There is no doubt loop{0..7} was associated with snap, see bellow the output of command before removing snap :

>$ lsblk -a
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0                       7:0    0  63.5M  1 loop /snap/core20/2015
loop1                       7:1    0 111.9M  1 loop /snap/lxd/24322
loop2                       7:2    0    87M  1 loop /snap/lxd/27037
loop3                       7:3    0  53.3M  1 loop /snap/snapd/19457
loop4                       7:4    0  40.4M  1 loop /snap/snapd/20671
loop5                       7:5    0  63.9M  1 loop /snap/core20/2182
loop6                       7:6    0     0B  0 loop
loop7                       7:7    0     0B  0 loop
sda                         8:0    0 279.4G  0 disk
├─sda1                      8:1    0     1M  0 part
[...]

Answer 1

Those loop devices are not necessarily specifically created for SNAP or any other app for that matter, although free ones can be utilized for any app that needs a loop device at any time.

Those 0-7 are automatically created at init time by the kernel (regardless of the presence of the SNAP package manager or the snapd daemon)... Quoting from The kernel’s command-line parameters:

max_loop=       [LOOP] The number of loop block devices that get
(loop.max_loop) unconditionally pre-created at init time. The default
                number is configured by BLK_DEV_LOOP_MIN_COUNT. Instead
                of statically allocating a predefined number, loop
                devices can be requested on-demand with the
                /dev/loop-control interface. 

... max_loop= used to be set to 8 for historical functionality limitation of losetup(8) not being able to dynamically create new loop block devices at run-time before the utilization of the /dev/loop-control interface to do that became possible around the year 2011 ... Which then became both unneeded and none-preferably hard limiting ... Quoting from [PATCH 3/3] loop: add BLK_DEV_LOOP_MIN_COUNT=%i to allow distros 0 pre-allocated loop devices:

+ /*
+  * If max_loop is specified, create that many devices upfront.
+  * This also becomes a hard limit. If max_loop is not specified,
+  * create CONFIG_BLK_DEV_LOOP_MIN_COUNT loop devices at module
+  * init time. Loop devices can be requested on-demand with the
+  * /dev/loop-control interface, or be instantiated by accessing
+  * a 'dead' device node.
+  */ 

... so it now appears to be set to 0/unspecified ... Moreover, quoting from [PATCH v1] loop: Fix the max_loop commandline argument treatment when it is set to 0:

The max_loop commandline argument can be used to override the
value of CONFIG_BLK_DEV_LOOP_MIN_COUNT. However, when max_loop is set
to 0 through the commandline, the current logic treats it as if it had
not been set, and creates CONFIG_BLK_DEV_LOOP_MIN_COUNT devices
anyway. 

... and CONFIG_BLK_DEV_LOOP_MIN_COUNT in Ubuntu is:

$ grep 'CONFIG_BLK_DEV_LOOP_MIN_COUNT' /boot/config-"$(uname -r)"
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8

... also reflected in:

$ cat /sys/module/loop/parameters/max_loop 
8

Therefore you can limit the number of loop devices created during boot time under current kernels to one by setting the kernel's boot parameter "max_loop=1" in your boot manager i.e. GRUB and supposedly to none under future patched kernels with "max_loop=0" ... and that shouldn't affect future reinstall of the SNAP package management system as loop devices should be dynamically created as needed.

Answer 2

The existence of loop{0..7} is not related to snap. Snap merely used 6 of them. Just because snap used 1GB of your hard disk, doesn't mean that you need to throw away your 1TB hard disk to get rid of snap.

If you run ls /dev in https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg&mem=192 , you will see the loop{0..7}. That is Alpine Linux, and is not based off of Ubuntu, so it never supported snap. Yet without snap, it still has those loop devices. This is normal.