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

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]


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?


Then I tried detaching and removing at the same time:

   # ./losetup -R -d loop4

No feedback, but it didn't do anything:

   # ./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?

   # ./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
   # ./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.

In my opinion --remove is not a good name for the option, as it doesn't
actually remove anything.  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.

But what is the purpose of --unlist?  Why would one want it?  What harm
is there in listing empty, fallow loop devices?

   # ./lsblk -a | grep loop
   loop0         7:0    0     0B  0 loop
   loop1         7:1    0     0B  0 loop
   loop2         7:2    0     0B  0 loop
   loop3         7:3    0     0B  0 loop
   loop4         7:4    0   400M  0 loop
   loop5         7:5    0     0B  0 loop
   loop6         7:6    0     0B  0 loop
   loop7         7:7    0     0B  0 loop


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Nuno Silva]

On 2025-10-10, 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?

For all commands after this one in your message, where there was no
output, what was the exit status?

[...]
> 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?

The online manual here says that -d takes one argument, so my
understanding is that that is expected? (Just as for -R, apparently:)

>   # ./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.

[...]

-- 
Nuno Silva

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 925 bytes --]


Op 11-10-2025 om 12:16 schreef Nuno Silva:
> For all commands after this one in your message, where there was no
> output, what was the exit status?

The answer is below.

>>    # ./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?
> 
> The online manual here says that -d takes one argument, so my
> understanding is that that is expected?

Agreed.  (It's just that I expected the tool to be cleverer.)

>>    # ./losetup -d loop4 -R loop4

   # echo $?
   1

So it didn't actually work.  It only works (and has exit status 0)
when having a done a plain `./losetup -d loop4` beforehand.

Seeing that four options (-d, -D, -c, -R) are more like commands,
maybe those should be made mutually exclusive?  Meaning that
losetup` should barf when more than one of them is given?


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Karel Zak]

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  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Karel Zak]

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"):

https://github.com/util-linux/util-linux/pull/3803

A new PR, summary:

 - losetup: add error feedback for --remove command - Improves error
   reporting in the remove_loop() function so users see meaningful
   error messages when removal fails.

 - losetup: make --remove a long-only option with mutual exclusivity -
   Removes the -R short option (keeping only --remove) and adds mutual
   exclusivity with other major operations like -d, -D, -a, -c, -f,
   -j, -l, and -O. Updates man page, bash completion, and usage text.

 - losetup: improve --remove documentation - Rewrites the --remove
   description and adds a new "LOOP DEVICE LIFECYCLE" section
   explaining the difference between creation, detachment, and removal
   operations.

 Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 348 bytes --]


Op 16-10-2025 om 12:28 schreef Karel Zak:
> https://github.com/util-linux/util-linux/pull/3803

Looks good to me.  In particular the documentation patch: it was the
poor description of --remove that made me scrutinize `losetup`.  :)

It would be nice, though, to see a Reported-by tag on the first patch,
the error feedback.


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 679 bytes --]


Op 16-10-2025 om 12:28 schreef Karel Zak:
> https://github.com/util-linux/util-linux/pull/3803

Misusing the tool now gives a surprising a result:

   # ./losetup --remove --detach
   losetup: /dev/--detach: remove failed: Success

   # ./losetup --remove --detach loop0
   losetup: /dev/--detach: remove failed: Success
   losetup: /dev/loop0: remove failed: Device or resource busy

Ideally, `losetup` would first interpret all options, and complain
that --remove and --detach cannot be combined.  (The code for that
seems to be there, but it doesn't appear to have any effect.)

But at least it shouldn't print "Success" when something failed.


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Karel Zak]

On Fri, Oct 17, 2025 at 10:55:17AM +0200, Benno Schulenberg wrote:
> 
> Op 16-10-2025 om 12:28 schreef Karel Zak:
> > https://github.com/util-linux/util-linux/pull/3803
> 
> Misusing the tool now gives a surprising a result:
> 
>   # ./losetup --remove --detach
>   losetup: /dev/--detach: remove failed: Success
> 
>   # ./losetup --remove --detach loop0
>   losetup: /dev/--detach: remove failed: Success
>   losetup: /dev/loop0: remove failed: Device or resource busy

Ah, this is unpleasant. Thank you for reporting it. 

> Ideally, `losetup` would first interpret all options, and complain
> that --remove and --detach cannot be combined.  (The code for that
> seems to be there, but it doesn't appear to have any effect.)
> 
> But at least it shouldn't print "Success" when something failed.

Both issues should be fixed in the branch. I have changed how it uses
--detach, --remove, and --set-capacity to assume the device name
follows the options rather than requiring it as an option's argument.

It returns the mutually exclusive check to the game and avoids
interpreting an option as a device name.

 # ./losetup --remove --detach loop0
 losetup: mutually exclusive arguments: --detach-all --all --set-capacity --detach --find --associated --remove

 Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]


Op 21-10-2025 om 12:00 schreef Karel Zak:
> Both issues should be fixed in the branch. I have changed how it uses
> --detach, --remove, and --set-capacity to assume the device name
> follows the options rather than requiring it as an option's argument.
> 
> It returns the mutually exclusive check to the game and avoids
> interpreting an option as a device name.

Nice.  Thanks.

>   # ./losetup --remove --detach loop0
>   losetup: mutually exclusive arguments: --detach-all --all --set-capacity --detach --find --associated --remove

Nnn...  My next report was going to be about this.  :)  About too verbose
and therefore confusing feedback.  The user did not specify --detach-all,
nor --all, nor --set-capacity, nor --find, nor --associated.  Thus it is
confusing to see them mentioned in the error message.

It would be much nicer if the routine that checks for conflicting options
would just print the first two incompatible ones of the options that were
actually given.  For example:

   # ./losetup --remove --find --all
   losetup: options --remove and --find cannot be combined


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Karel Zak]

On Tue, Oct 21, 2025 at 03:49:01PM +0200, Benno Schulenberg wrote:
> >   # ./losetup --remove --detach loop0
> >   losetup: mutually exclusive arguments: --detach-all --all --set-capacity --detach --find --associated --remove
> 
> Nnn...  My next report was going to be about this.  :) 

 :-)

> About too verbose
> and therefore confusing feedback.  The user did not specify --detach-all,
> nor --all, nor --set-capacity, nor --find, nor --associated.  Thus it is
> confusing to see them mentioned in the error message.
> 
> It would be much nicer if the routine that checks for conflicting options
> would just print the first two incompatible ones of the options that were
> actually given.  For example:
> 
>   # ./losetup --remove --find --all
>   losetup: options --remove and --find cannot be combined
 
Implemented:
    https://github.com/util-linux/util-linux/pull/3835


   Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 724 bytes --]


Op 03-11-2025 om 13:49 schreef Karel Zak:
>>    # ./losetup --remove --find --all
>>    losetup: options --remove and --find cannot be combined
>   
> Implemented:
>      https://github.com/util-linux/util-linux/pull/3835

Thanks!  However...

	fprintf(stderr, _("%s: options "), program_invocation_short_name);
	ul_print_option(stderr, status[e], opts);
	fputs(_(" and "), stderr);
	ul_print_option(stderr, c, opts);
	fputs(_(" cannot be combined.\n"), stderr);

For translatability, the above should be like:

	fprintf(stderr, _("%s: options %s and %s cannot be combined"), ...);


See for example `info gettext prep prep`, saying that translatable strings
should be entire sentences.


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Karel Zak]

On Mon, Nov 03, 2025 at 03:42:50PM +0100, Benno Schulenberg wrote:
> 
> Op 03-11-2025 om 13:49 schreef Karel Zak:
> > >    # ./losetup --remove --find --all
> > >    losetup: options --remove and --find cannot be combined
> > Implemented:
> >      https://github.com/util-linux/util-linux/pull/3835
> 
> Thanks!  However...
> 
> 	fprintf(stderr, _("%s: options "), program_invocation_short_name);
> 	ul_print_option(stderr, status[e], opts);
> 	fputs(_(" and "), stderr);
> 	ul_print_option(stderr, c, opts);
> 	fputs(_(" cannot be combined.\n"), stderr);
> 
> For translatability, the above should be like:
> 
> 	fprintf(stderr, _("%s: options %s and %s cannot be combined"), ...);
> 
> 
> See for example `info gettext prep prep`, saying that translatable strings
> should be entire sentences.

Yes, I know. The problem is that we need an extra buffer in the case
of the short-only option. I have updated the pull request to make it
more elegant. Now it uses:

    errx(OPTUTILS_EXIT_CODE,
        _("options %s%s and %s%s cannot be combined"),
        ....

so it's just one string.

    Karel




-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]


Op 07-11-2025 om 11:16 schreef Karel Zak:
> On Mon, Nov 03, 2025 at 03:42:50PM +0100, Benno Schulenberg wrote:
>> For translatability, the above should be like:
>>
>> 	fprintf(stderr, _("%s: options %s and %s cannot be combined"), ...);
> 
> Yes, I know. The problem is that we need an extra buffer in the case
> of the short-only option. I have updated the pull request to make it
> more elegant. Now it uses:
> 
>      errx(OPTUTILS_EXIT_CODE,
>          _("options %s%s and %s%s cannot be combined"),
>          ....


That wil work.  Thanks!


In the commit message it says for NEW:

     $ losetup --remove --detach loop0
     losetup: options --detach and --remove cannot be combined.

But the actual error message is:

     losetup: options --remove and --detach cannot be combined

(the options in the order as on the command line and without a period).


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]