losetup: failed to setup loop device > 1

DISCUSSION Francis Moreau 2 participants 9 messages Oct 6, 2014 – Oct 8, 2014 Util-Linux package

lore

Share & tools

lore

Francis Moreau

author

2014-10-06 16:32 UTC #0 lore raw

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.

Karel Zak

maintainer

2014-10-06 17:40 UTC #1 lore raw

Quoted 2 lines · Francis Moreau

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

Quoted 1 line

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

Signature · 2 lines

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

Francis Moreau

author

2014-10-06 20:56 UTC #2 lore raw

Quoted 11 lines · Karel Zak

Quoted 2 lines · Francis Moreau
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
Quoted 1 line
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 :-/

Karel Zak

maintainer

2014-10-07 09:17 UTC #3 lore raw

Quoted 13 lines · Francis Moreau

Quoted 11 lines · Karel Zak
Quoted 2 lines · Francis Moreau
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
Quoted 1 line
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.

Quoted 7 lines

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

Signature · 2 lines

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

Francis Moreau

author

2014-10-07 09:32 UTC #4 lore raw

Quoted 22 lines · Karel Zak

Quoted 13 lines · Francis Moreau
Quoted 11 lines · Karel Zak
Quoted 2 lines · Francis Moreau
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
Quoted 1 line
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.
Quoted 7 lines
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 :-/

Quoted 6 lines

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

Francis Moreau

author

2014-10-08 08:57 UTC #5 lore raw

Quoted 27 lines · Francis Moreau

Quoted 26 lines · Karel Zak
Quoted 13 lines · Francis Moreau
Quoted 11 lines · Karel Zak
Quoted 2 lines · Francis Moreau
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
Quoted 1 line
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.
Quoted 7 lines
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.

Quoted 9 lines

Quoted 2 lines
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

Karel Zak

maintainer

2014-10-08 09:44 UTC #6 lore raw

Quoted 4 lines · Francis Moreau

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

Signature · 2 lines

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

Francis Moreau

author

2014-10-08 10:03 UTC #7 lore raw

Quoted 8 lines · Karel Zak

Quoted 4 lines · Francis Moreau
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 ;)

Quoted 5 lines

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

Francis Moreau

author

2014-10-08 10:56 UTC #8 lore raw

In reply to Karel Zak

Quoted 18 lines · Karel Zak

Quoted 17 lines · Francis Moreau
Quoted 11 lines · Karel Zak
Quoted 2 lines · Francis Moreau
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
Quoted 1 line
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...

Quoted 7 lines

Quoted 3 lines
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.