losetup --find reports a lost loop device even in a container

[mrc0mmand]

While trying to upgrade a Fedora Rawhide job in our upstream systemd CI I noticed one strange test fail. This test uses losetup --find to check if loop devices are available (which is admittedly not ideal), and since a6ca045 and 556dac8 this reports a lost loop device even in a container without access to loop devices:

# systemd-nspawn -D / --volatile=yes bash
Spawning container localhost.localdomain on /.
Press Ctrl-] three times within 1s to kill container.
bash-5.2# stat /dev/loop-control
stat: cannot statx '/dev/loop-control': No such file or directory
bash-5.2# losetup --find
/dev/loop0 (lost)
bash-5.2# echo $?
0

Is this expected?

Reproducible with both util-linux-2.40-0.11.rc1.fc41.x86_64 and latest master.

[karelzak]

The file /dev/loop-control is optional, and if it's not available, then it scans for /dev/loopN files. It seems that it was able to get /dev/loop0, but later it disappeared, so it's reported as lost.

LOOPDEV_DEBUG=all losetup --find may provide more details.

Not sure why do you see the problem (maybe more tests running in parallel, udevadm settle is good friend).
I'm not able to reproduce it:

# systemd-nspawn -D / --volatile=yes bash
Spawning container vm-10-0-187-68.hosted.upshift.rdu2.redhat.com on /.
Press Ctrl-] three times within 1s to kill container.

bash-5.2#  losetup --find
/dev/loop0
bash-5.2# losetup -V
losetup from util-linux 2.40-rc1

[mrc0mmand]

Ah, interesting, thank you. I think the reason here why this happens is that I have (or had) /dev/loop0 used on the host machine, so it's then reported as lost in the container, since it's not there (but it's still present in /sys).

[root@localhost ~]# losetup --find
/dev/loop0
[root@localhost ~]# systemd-nspawn -D / --volatile=yes --bind $PWD:/build bash
Spawning container localhost.localdomain on /.
Press Ctrl-] three times within 1s to kill container.
bash-5.2# LOOPDEV_DEBUG=all losetup --find
2: loopdev:      CXT: [0x7ffc49e1e7d0]: initialize context
2: loopdev:      CXT: [0x7ffc49e1e7d0]: init: ignore ioctls
2: loopdev:      CXT: [0x7ffc49e1e7d0]: find_unused requested
2: loopdev:      CXT: [0x7ffc49e1e7d0]: using loop scan
2: loopdev:     ITER: [0x7ffc49e1e9b8]: initialize
2: loopdev:     ITER: [0x7ffc49e1e9b8]: next
2: loopdev:     ITER: [0x7ffc49e1e9b8]: next: default check
2: loopdev:      CXT: [0x7ffc49e1e7d0]: loop0 name assigned
2: loopdev:      CXT: [0x7ffc49e1e7d0]: get_offset [rc=-22]
2: loopdev:     ITER: [0x7ffc49e1e9b8]: de-initialize
2: loopdev:      CXT: [0x7ffc49e1e7d0]: find_unused by scan [rc=0]
/dev/loop0 (lost)
2: loopdev:      CXT: [0x7ffc49e1e7d0]: de-initialize
2: loopdev:     ITER: [0x7ffc49e1e9b8]: de-initialize
# ls /sys/block/
loop0  vda  zram0

So I guess the test needs to be updated on our side, to not use losetup --find to check if loop devices are available.

[karelzak]

Maybe losetup should be more competent when testing if the device is used.

Now (in your case) it checks for "offset" (sysfs file loop/offset, the file is missing so it assumes the device is unused). Maybe when it scans for the devices in sysfs it should also check for the device lost and ignore such devices.