losetup: failed to setup loop device > 1

losetup: failed to setup loop device > 1

[Francis Moreau]

Hello,

I don't really understand what's going on, it seems that I can't setup a
loop device if loop0 is already in use.

If no loop is in use, everything works as expected:

# LOOPDEV_DEBUG=1 losetup -f disk.img
loopdev:  [0x7fffaf57c898]: find_unused requested
loopdev:  [0x7fffaf57c898]: loop0 successfully assigned
loopdev:  [0x7fffaf57c898]: find_unused by loop-control [rc=0]
loopdev:  [0x7fffaf57c898]: set backing file=/root/diskt.img
loopdev:  [0x7fffaf57c898]: device setup requested
loopdev:  [0x7fffaf57c898]: setup: backing file open: OK
loopdev:  [0x7fffaf57c898]: open ok
loopdev:  [0x7fffaf57c898]: setup: device open: OK
loopdev:  [0x7fffaf57c898]: setup: LOOP_SET_FD: OK
loopdev:  [0x7fffaf57c898]: setup: LOOP_SET_STATUS64: OK
loopdev:  [0x7fffaf57c898]: setup success [rc=0]
loopdev:  [0x7fffaf57c898]: de-initialize
loopdev:  [0x7fffaf57c898]: iter: de-initialize

However if loop0 is busy, it fails this way:

# LOOPDEV_DEBUG=1 losetup -f disk.img
loopdev:  [0x7fff15a8da98]: find_unused requested
loopdev:  [0x7fff15a8da98]: loop1 successfully assigned
loopdev:  [0x7fff15a8da98]: find_unused by loop-control [rc=0]
loopdev:  [0x7fff15a8da98]: set backing file=/root/disk.img
loopdev:  [0x7fff15a8da98]: device setup requested
loopdev:  [0x7fff15a8da98]: setup: backing file open: OK
loopdev:  [0x7fff15a8da98]: open failed
loopdev:  [0x7fff15a8da98]: setup failed [rc=-6]
losetup: failed to setup loop device: No such device or address
loopdev:  [0x7fff15a8da98]: de-initialize
loopdev:  [0x7fff15a8da98]: iter: de-initialize

The weird thing is that loop1 is succesfully found/allocated but it
failed during the open() of the device.

strace shows:
...
open("/dev/loop-control", O_RDWR)       = 0
ioctl(0, 0x4c82, 0x3)                   = 1
...
open("/dev/loop1", O_RDWR)              = -1 ENXIO (No such device or
address)
...

The loop min count for that system is 8 so it shouldn't be a problem to
setup 2 loop devices and the trace shows that requesting a new loop works.

One last details is that the system uses pretty old stuff: kernel
3.4.50, util-linux 2.21.1.

Could anybody give me some help ?

Thanks.

Re: losetup: failed to setup loop device > 1

[Karel Zak]

On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
> One last details is that the system uses pretty old stuff: kernel
> 3.4.50, util-linux 2.21.1.

$ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
62

> Could anybody give me some help ?

update, this is upstream mailing list I have doubts anyone is ready
to help you with code released 2 years ago.

    Karel

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

Re: losetup: failed to setup loop device > 1

[Francis Moreau]

On 10/06/2014 07:40 PM, Karel Zak wrote:
> On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
>> One last details is that the system uses pretty old stuff: kernel
>> 3.4.50, util-linux 2.21.1.
> 
> $ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
> 62
> 
>> Could anybody give me some help ?
> 
> update, this is upstream mailing list I have doubts anyone is ready
> to help you with code released 2 years ago.

well it looks like more a kernel issue since the sequence of syscalls
done by losetup looks correct. Maybe someone here already encountered
this...

I just found that loop module was loaded with max_part=16 and
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8. If max_part is set to 0 then the issue
is gone :-/

Re: losetup: failed to setup loop device > 1

[Karel Zak]

On Mon, Oct 06, 2014 at 10:59:00PM +0200, Francis Moreau wrote:
> On 10/06/2014 07:40 PM, Karel Zak wrote:
> > On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
> >> One last details is that the system uses pretty old stuff: kernel
> >> 3.4.50, util-linux 2.21.1.
> > 
> > $ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
> > 62
> > 
> >> Could anybody give me some help ?
> > 
> > update, this is upstream mailing list I have doubts anyone is ready
> > to help you with code released 2 years ago.
> 
> well it looks like more a kernel issue since the sequence of syscalls
> done by losetup looks correct. Maybe someone here already encountered
> this...
> 
> I just found that loop module was loaded with max_part=16 and
> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8. If max_part is set to 0 then the issue
> is gone :-/

Well, if you have kernel that provides /dev/loop-control then you
don't have to set CONFIG_BLK_DEV_LOOP_MIN_COUNT at all. I guess 
"8" (kernel upstream default?) is mostly about backward compatibility.

For example fedora uses CONFIG_BLK_DEV_LOOP_MIN_COUNT=0. All is
dynamically allocated by kernel + udev.

    Karel

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

Re: losetup: failed to setup loop device > 1

[Francis Moreau]

On 10/07/2014 11:17 AM, Karel Zak wrote:
> On Mon, Oct 06, 2014 at 10:59:00PM +0200, Francis Moreau wrote:
>> On 10/06/2014 07:40 PM, Karel Zak wrote:
>>> On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
>>>> One last details is that the system uses pretty old stuff: kernel
>>>> 3.4.50, util-linux 2.21.1.
>>>
>>> $ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
>>> 62
>>>
>>>> Could anybody give me some help ?
>>>
>>> update, this is upstream mailing list I have doubts anyone is ready
>>> to help you with code released 2 years ago.
>>
>> well it looks like more a kernel issue since the sequence of syscalls
>> done by losetup looks correct. Maybe someone here already encountered
>> this...
>>
>> I just found that loop module was loaded with max_part=16 and
>> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8. If max_part is set to 0 then the issue
>> is gone :-/
> 
> Well, if you have kernel that provides /dev/loop-control then you
> don't have to set CONFIG_BLK_DEV_LOOP_MIN_COUNT at all. I guess 
> "8" (kernel upstream default?) is mostly about backward compatibility.
> 
> For example fedora uses CONFIG_BLK_DEV_LOOP_MIN_COUNT=0. All is
> dynamically allocated by kernel + udev.

You're right, CONFIG_BLK_DEV_LOOP_MIN_COUNT can be set to 0. But that
doesnt explain my initial issue.

I have to understand why setting up a loop dev fails if the number of
loop used is > 1 and max_part != 0.

Thanks

Re: losetup: failed to setup loop device > 1

[Francis Moreau]

On 10/07/2014 11:32 AM, Francis Moreau wrote:
> On 10/07/2014 11:17 AM, Karel Zak wrote:
>> On Mon, Oct 06, 2014 at 10:59:00PM +0200, Francis Moreau wrote:
>>> On 10/06/2014 07:40 PM, Karel Zak wrote:
>>>> On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
>>>>> One last details is that the system uses pretty old stuff: kernel
>>>>> 3.4.50, util-linux 2.21.1.
>>>>
>>>> $ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
>>>> 62
>>>>
>>>>> Could anybody give me some help ?
>>>>
>>>> update, this is upstream mailing list I have doubts anyone is ready
>>>> to help you with code released 2 years ago.
>>>
>>> well it looks like more a kernel issue since the sequence of syscalls
>>> done by losetup looks correct. Maybe someone here already encountered
>>> this...
>>>
>>> I just found that loop module was loaded with max_part=16 and
>>> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8. If max_part is set to 0 then the issue
>>> is gone :-/
>>
>> Well, if you have kernel that provides /dev/loop-control then you
>> don't have to set CONFIG_BLK_DEV_LOOP_MIN_COUNT at all. I guess 
>> "8" (kernel upstream default?) is mostly about backward compatibility.
>>
>> For example fedora uses CONFIG_BLK_DEV_LOOP_MIN_COUNT=0. All is
>> dynamically allocated by kernel + udev.
> 
> You're right, CONFIG_BLK_DEV_LOOP_MIN_COUNT can be set to 0. But that
> doesnt explain my initial issue.
> 
> I have to understand why setting up a loop dev fails if the number of
> loop used is > 1 and max_part != 0.
> 

In HEAD of the git tree, in file losetup.c, the return value of
loopcxt_add_device() is not checked in main().

Is this expected ?

Thanks

Re: losetup: failed to setup loop device > 1

[Karel Zak]

On Wed, Oct 08, 2014 at 10:57:25AM +0200, Francis Moreau wrote:
> In HEAD of the git tree, in file losetup.c, the return value of
> loopcxt_add_device() is not checked in main().
> 
> Is this expected ?

Good question :-)

The loop-control is optional (from the code point of view). If the system 
does not have control file (old kernels) and on command line specified loop
device does not exist then it will end with open() error later
(in loopcxt_setup_device()).

Yes, we can improve the main() and add an error message there, but no
sure how usable it will be for end-users (open() errors are pretty
obvious compare to all possible situations in loopcxt_add_device()).

 Karel

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

Re: losetup: failed to setup loop device > 1

[Francis Moreau]

On 10/08/2014 11:44 AM, Karel Zak wrote:
> On Wed, Oct 08, 2014 at 10:57:25AM +0200, Francis Moreau wrote:
>> In HEAD of the git tree, in file losetup.c, the return value of
>> loopcxt_add_device() is not checked in main().
>>
>> Is this expected ?
> 
> Good question :-)
> 

At least one ;)

> The loop-control is optional (from the code point of view). If the system 
> does not have control file (old kernels) and on command line specified loop
> device does not exist then it will end with open() error later
> (in loopcxt_setup_device()).
> 

in losetup.c, line 638:

		if (hasdev && !is_loopdev(loopcxt_get_device(&lc)))
			loopcxt_add_device(&lc);

I don't really see why having loop-control here or not matter: in both
case you want to stop if loopcxt_add_device() fails, no ?

If it fails then the loop device node, doesn't exist.

Thanks

Re: losetup: failed to setup loop device > 1

[Francis Moreau]

On 10/07/2014 11:17 AM, Karel Zak wrote:
> On Mon, Oct 06, 2014 at 10:59:00PM +0200, Francis Moreau wrote:
>> On 10/06/2014 07:40 PM, Karel Zak wrote:
>>> On Mon, Oct 06, 2014 at 06:35:20PM +0200, Francis Moreau wrote:
>>>> One last details is that the system uses pretty old stuff: kernel
>>>> 3.4.50, util-linux 2.21.1.
>>>
>>> $ git log --oneline v2.21.. -- lib/loopdev.c sys-utils/losetup.c | wc -l
>>> 62
>>>
>>>> Could anybody give me some help ?
>>>
>>> update, this is upstream mailing list I have doubts anyone is ready
>>> to help you with code released 2 years ago.
>>
>> well it looks like more a kernel issue since the sequence of syscalls
>> done by losetup looks correct. Maybe someone here already encountered
>> this...
>>
>> I just found that loop module was loaded with max_part=16 and
>> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8. If max_part is set to 0 then the issue
>> is gone :-/
> 
> Well, if you have kernel that provides /dev/loop-control then you
> don't have to set CONFIG_BLK_DEV_LOOP_MIN_COUNT at all. I guess 
> "8" (kernel upstream default?) is mostly about backward compatibility.

BTW it not depends only on the kernel and /dev/loop-control but also on
losetup(8) to be recent enough to add a new loop device if the one
specified doesn't exist. And I don't think it's the case for losetup
shipped by util-linux 2.21.1

Thanks.