Score:3

Who/what is creating /dev/loop0, /dev/loop1, ... /dev/loop7?

sa flag

I've recently been working on a project requiring encrypted files mounted via a connection to a loop device. While the project will run on an Ubuntu system, I was experimenting with setting it up on my Arch Linux workstation. That's when I noticed that Arch doesn't have any loop devices initialized by default, while all the Ubuntu systems I checked (ranging from 18.04 to 22.10) always have 8 pre-created loop devices. This kind of makes sense, since you need elevated privileges to run

losetup -f

On the other hand, the permissions on /dev/loopN don't allow ordinary users to use them anyway. But in any case I can't figure out who/what is creating these devices. I've looked over the udev rules in /lib/udev/rules.d, and couldn't find anything relevant. I also looked through the systemd service files in /lib/systemd/system and couldn't find anything there, either. This is mostly a curiosity question, as I hate magical events in my operating systems.

Here is the evidence that there are no snaps mounted on this system

root@texas-tea:~# ls /dev/loop*
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control
/dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
root@texas-tea:~# lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 238.5G  0 disk  
├─sda1                          8:1    0   714M  0 part  /boot
├─sda2                          8:2    0     1K  0 part  
└─sda5                          8:5    0 237.8G  0 part  
  └─sda5_crypt                253:0    0 237.8G  0 crypt 
    ├─vgtexas--tea-root       253:1    0  47.7G  0 lvm   /
    ├─vgtexas--tea-swap_1     253:2    0   3.7G  0 lvm   [SWAP]
    ├─vgtexas--tea-var        253:3    0  23.9G  0 lvm   /var
    ├─vgtexas--tea-var+condor 253:4    0   952M  0 lvm   /var/condor
    ├─vgtexas--tea-tmp        253:5    0  11.9G  0 lvm   /tmp
    └─vgtexas--tea-var+local  253:6    0 149.7G  0 lvm   /var/local
sr0                            11:0    1  1024M  0 rom   
root@texas-tea:~# mount | grep loop
root@texas-tea:~# 
root@texas-tea:~# losetup -l
root@texas-tea:~# 

EDIT: I recently became aware that loop devices can be created as a compile time option or passed as a kernel parameter (see max_loop= here: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html) Checking /etc/default/[grub|grub.d] I don't see anything related being passed as a kernel parameter on boot, so my current best guess is that the Ubuntu kernel compilers are setting BLK_DEV_LOOP_MIN_COUNT=8 in the build configuration.

pgoetz avatar
sa flag
Unfortunately, no. In particular, checking the 18.04 machine I use in the office there are the usual 8 loop devices, but `losetup -a` doesn't show any of them being in use.
user535733 avatar
cn flag
Seems like perhaps you missed the point of that duplicate.
pgoetz avatar
sa flag
Please explain. It's not a duplicate, or even a related question. There are mounted snaps on the 22.10 machine I checked but none on the 18.04 machine.
user535733 avatar
cn flag
The most common explanation by far is the presence of snap packages, hence the duplicate. If there are mysterious loop-mounts *without* snaps on the 18.04 machine, then edit your question to show appropriate lsblk and df and snapd output. We will need those clues.
Artur Meinild avatar
vn flag
Please include some evidence. If you want this to be reopened, please list output of the commands `lsblk` and `losetup -l` in your question.
pgoetz avatar
sa flag
I mean, it's likely that the snap package is somehow responsible for the creation of these unused loop devices, but I would like to know how. I do not appreciate magical things happening on my linux machines which is why I use Arch linux whenever possible. Unfortunately this isn't an option at work. I've edited my original question to demonstrate there are no snaps mounted on the machine.
muru avatar
us flag
What was the installation process for setting up this snap-less Ubuntu system? Without knowing how to reproduce this, it's hard to tell you where to look for the cause. As for magical things happening... I have an Arch Linux with `% ls /dev/loop*` => `/dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7 /dev/loop-control` and without snap installed. I'd guess this is just from [the `loop` module being loaded at all](https://unix.stackexchange.com/a/554445/70524).
Score:-1
cn flag
raj

Type lsblk (or even df) and you will see "who/what is creating" these devices :)

These loop devices are mount points for installed snap packages. Each snap package uses one device.

mook765 avatar
cn flag
No, loop devices are not mountpoints, they are devices that get mounted and you can see their mountpoints (which are usually folders) when you type `lsblk`. The mounts are created by systemd and you can find the correspondig `.mount`-files in `/etc/systemd/system`.
pgoetz avatar
sa flag
@mook765 Unfortunately I can't find *any* .mount files in /etc/systemd/system. `find . -depth -iname \*.mount` returns nothing.
pgoetz avatar
sa flag
@raj As pointed out by mook765, loop devices are not mountpoints, nor are they block devices. They don't show up in `lslbk` unless you bind them to something. For example, if I run `losetup /dev/loop0 my-file-to-mount.img` loop0 will show up in lsblk. When I run lsblk on the ubuntu systems I'm looking at, no loop devices show up in `lsblk` indicating they're not bound to anything.
Artur Meinild avatar
vn flag
This obviously isn't the case here...
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.