Re: `losetup --remove` is confusing, and misuse silently fails

On Fri, Oct 10, 2025 at 11:41:08AM +0200, Benno Schulenberg wrote:
> 
> After setting up a loop device with:
> 
>   # ./losetup loop4 some.img
> 
> I wanted to see what happens when trying to "remove" it
> (since the man page says it is "not recommended"):
> 
>   # ./losetup -R loop4
> 
> There is no feedback, but it failed:
> 
>   # echo $?
>   1
> 
> When a command fails, shouldn't it print an error message?

Yes, we need to fix it.

> Then I tried detaching and removing at the same time:
> 
>   # ./losetup -R -d loop4
> 
> No feedback, but it didn't do anything:

The options need to be mutually exclusive.

>   # ./losetup loop4
>   /dev/loop4: [66306]:5939273 (/home/ben/Sources/util-linux/some.img)
> 
> Trying a different order of the options:
> 
>   # ./losetup -d -R loop4
>   losetup: /dev/-R: detach failed: No such file or directory
> 
> Huh?  Why does it try to interpret an option as a loop device name?

-d and -R requires argument.

>   # ./losetup -d loop4 -R
>   /home/ben/Sources/util-linux/.libs/losetup: option requires an argument -- 'R'
>   Try 'losetup --help' for more information.
> 
>   # ./losetup -d loop4 -R loop4
> 
> Oh.  Surprisingly, this last invocation worked.
> 
>   # ls -l /dev/loop? | grep loop4
>   # lsblk -a | grep loop4
> 
> 
> However, the loop4 device is not really gone, because one can attach
> a file to it again:
> 
>   # ./losetup --show loop4 some.img
>   /dev/loop4

This is expected. losetup asks kernel to create the node again.

>   # ./losetup -a
>   /dev/loop4: [66306]:5939273 (/home/ben/Sources/util-linux/some.img)
> 
> When the device is really gone, attaching doesn't work:
> 
>   # rm /dev/loop3
>   # ./losetup loop3 some.img
>   losetup: /dev/loop3: failed to set up loop device: No such file or directory
>   losetup: device node /dev/loop3 (7:3) is lost. You may use mknod(1) to
> recover it.

This is because according to kernel there is the node, but you have
manually removed the /dev/loop3 file. This is mostly udevd playground,
losetup is able to detect "lost node" situation, it's enough I think.
We can improve is losetup man page to explain it.

> In my opinion --remove is not a good name for the option, as it doesn't
> actually remove anything.

It asks kernel to remove the node (and it's processed by udevd I
guess). The ioctl name is LOOP_CTL_REMOVE.

> Also, its meaning is too similar to "detach":
> when the computer asks me to "Remove the USB stick", I detach this stick
> from the USB port.
> 
> What --remove accomplishes is that it prevents the specified loop device
> from getting listed.  So in my opinion a better name for the option would
> be: --unlist.

I think --remove is fine, but it needs to be implemented in more
verbose way and with more respect to the end users.

> But what is the purpose of --unlist?  Why would one want it? 

Well, we provide command line interface to kernel features :-)

> What harm is there in listing empty, fallow loop devices?

Maybe someone needs to optimize devices scanning, size of /sys
etc. The number of loopdevs can be large on some servers.

    Karel


-- 
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com