Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238203 > unrolled thread

losetup: cannot find an unused loop device , kernel config of loopback device

Back to article view | Back to linux.debian.user

Contents

  losetup: cannot find an unused loop device , kernel config of  loopback device Colin Williams <colin.williams.seattle@gmail.com> - 2021-08-05 14:00 +0200
    Re: losetup: cannot find an unused loop device , kernel config of  loopback device <tomas@tuxteam.de> - 2021-08-05 14:10 +0200
    Re: losetup: cannot find an unused loop device , kernel config of loopback device "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-05 15:10 +0200
      Re: losetup: cannot find an unused loop device , kernel config of  loopback device The Wanderer <wanderer@fastmail.fm> - 2021-08-05 15:40 +0200
        Re: losetup: cannot find an unused loop device , kernel config of loopback device "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-05 16:10 +0200
      Re: losetup: cannot find an unused loop device , kernel config of  loopback device Colin Williams <colin.williams.seattle@gmail.com> - 2021-08-07 07:10 +0200
        Re: losetup: cannot find an unused loop device , kernel config of  loopback device <tomas@tuxteam.de> - 2021-08-07 09:50 +0200
        Re: losetup: cannot find an unused loop device , kernel config of loopback device "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-07 09:50 +0200
          Re: losetup: cannot find an unused loop device , kernel config of  loopback device Colin Williams <colin.williams.seattle@gmail.com> - 2021-08-07 10:30 +0200

#238203 — losetup: cannot find an unused loop device , kernel config of loopback device

I'm running bullseye / debian 11.0 testing. I have been running a
script that is supposed to write a filesystem image (for chromiumOS).
In short I'm getting the following

losetup: cannot find an unused loop device
partx: stat of  failed: No such file or directory
partx: stat of  failed: No such file or directory

Or for a greater description http://ix.io/3v3i

Looking up the error someone mentioned that the kernel needed to be
configured to support loopback devices. I was curious where the kernel
config is located. I looked at https://wiki.debian.org/KernelFAQ and
it seems to be extremely out of date. Referencing a 2.6 kernel and
mentioning kernel configs at /boot/ which are not existent on my
system.

Can someone tell me where I should look for the kernel for the
loopback setting?


Better yet, does anyone know how to solve my problem with the script
or losetup? Could this be an issue building from a chroot environment
with a different kernel version? Or building the image from a btrfs
filesystem?

[toc] | [next] | [standalone]

#238204

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 05, 2021 at 04:36:59AM -0700, Colin Williams wrote:
> I'm running bullseye / debian 11.0 testing. I have been running a
> script that is supposed to write a filesystem image (for chromiumOS).
> In short I'm getting the following
> 
> losetup: cannot find an unused loop device
> partx: stat of  failed: No such file or directory
> partx: stat of  failed: No such file or directory

Could you please do a quick

  sudo losetup -a

and perhaps

  ls /dev/loop*

and tell us the result?

> Looking up the error someone mentioned that the kernel needed to be
> configured to support loopback devices [...]

It would be an exotic kernel lacking that. Perhaps they are all used?

> Better yet, does anyone know how to solve my problem with the script
> or losetup? Could this be an issue building from a chroot environment
> with a different kernel version? Or building the image from a btrfs
> filesystem?

First let's try to understand what is going on. Perhaps some uncivilised
script has left around busy but unused loop devices.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#238209 — Re: losetup: cannot find an unused loop device , kernel config of loopback device

Hi,

> Can someone tell me where I should look for the kernel for the
> loopback setting?

Quite exactly a year ago i learned the hard way that it's
CONFIG_BLK_DEV_LOOP which on amd64 should be set to "m" to get /dev/loop*.
See its description at
  https://sources.debian.org/src/linux/5.10.46-1/drivers/block/Kconfig/#L174

But i'm somewhat puzzled by this statement at the end
  "Most users will answer N here."

A code search yields no BLK_DEV_LOOP=n
  https://codesearch.debian.net/search?q=package%3Alinux+BLK_DEV_LOOP%3Dn&literal=0
but lots of "y" and "m".

(Wasn't there a way to inquire the running kernel's configuration ?)

-----------------------------------------------------------------------

I see that tomas@tuxteam.de did not Cc you. In case you are not subscribed,
i repeat what he wrote:

> Could you please do a quick
>  sudo losetup -a
> and perhaps
>   ls /dev/loop*
> and tell us the result?
> [...] Perhaps they are all used?

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#238211

[Multipart message — attachments visible in raw view] — view raw

On 2021-08-05 at 09:04, Thomas Schmitt wrote:

> Hi,
> 
>> Can someone tell me where I should look for the kernel for the
>> loopback setting?
> 
> Quite exactly a year ago i learned the hard way that it's
> CONFIG_BLK_DEV_LOOP which on amd64 should be set to "m" to get /dev/loop*.
> See its description at
>   https://sources.debian.org/src/linux/5.10.46-1/drivers/block/Kconfig/#L174
> 
> But i'm somewhat puzzled by this statement at the end
>   "Most users will answer N here."

That does seem odd; at least in the modern Linux world, loopback-device
support is going to be expected if not required on the large majority of
systems. I can't rule out that this description may have been accurate
at one point, but unless an N here will mean that loopback-device
support will be provided by some other code path, it does indeed not
seem likely that it is what most users will/should say.

It might be worth filing a documentation-level kernel bug report about
this, or at least posting to the LKML to ask what the reasoning here is.

> A code search yields no BLK_DEV_LOOP=n
>   https://codesearch.debian.net/search?q=package%3Alinux+BLK_DEV_LOOP%3Dn&literal=0
> but lots of "y" and "m".
> 
> (Wasn't there a way to inquire the running kernel's configuration ?)

AFAIK, that's /proc/config.gz; it's present only if a specific Kconfig
setting is enabled, and Debian stopped enabling that setting quite some
years ago, apparently on the grounds that keeping the kernel config in
memory at all times is unnecessarily wasteful (especially with the
limited RAM that you see on e.g. embedded-type systems) vs. keeping it
on-disk.

At no later than that same time, Debian started putting the kernel
config on-disk instead, under the filename /boot/config-`uname -r`. If -
as the OP stated - the kernel config is not present in that location,
then either there's information we're not being provided, or something
is wrong.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#238213 — Re: losetup: cannot find an unused loop device , kernel config of loopback device

Hi,

The Wanderer wrote:
> It might be worth filing a documentation-level kernel bug report about
> this, or at least posting to the LKML to ask what the reasoning here is.

... together with a handful of sr and isofs bug fixes, if this was an
ideal world. {:)


I wrote:
> > (Wasn't there a way to inquire the running kernel's configuration ?)

The Wanderer wrote:
> Debian started putting the kernel
> config on-disk instead, under the filename /boot/config-`uname -r`.

Ah yes. That exists here and says
  CONFIG_BLK_DEV_LOOP=m

(Last year i igot missing CONFIG_BLK_DEV_LOOP by not running
   make oldconfig
 before compiling the kernel source.)


> If -
> as the OP stated - the kernel config is not present in that location,
> then either there's information we're not being provided, or something
> is wrong.

In any case i should read original posts more carefully.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#238303

Hello everyone,

In hindsight after looking at this much too late there were many
mistakes in my initial mail. The issue may or may not be debian
related and involves at least analyzing the script. There is a claim
in the documentation that

Then I'll make another attempt to further expose my ignorance.

1) kernels configs are located at /boot/. Not sure why I couldn't find
them. Perhaps a typo.

2) CONFIG_BLK_DEV_LOOP is set to M as expected. Using a file as a
loopback seems like it would be a common practice

3) I'm running a script /build_image --board=${BOARD}
--noenable_rootfs_verification dev whose output is shown in
http://ix.io/3v3i

4) I assume the script is supposed to create a file used as a loopback
device to write the image contents

5) The issue then might likely be script related and not debian related

6) I also posted to the chromium-dev google group, waiting for approval

7) I modified the build_image script with set -x, then recorded the
output: http://ix.io/3v6K

8) I believe the issues arise in
https://github.com/drocsid/cros-scripts/blob/main/common.sh which
seems to create the loopback file, etc.

9) from the log output shared above we see:
```++ sync -f /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
+++ sudo losetup --show -f
/mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
losetup: cannot find an unused loop device
++ lb_dev=
```

Then it appears that `sync -f
/mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin`
is the file we are trying to attach as a loopback device using
losetup.

10) The path /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
does not exist

11) However from the directory I'm working under a relative
./src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
exists. Then this appears to be the reason for the script errors

12) Looking around I found GCLIENT_ROOT set here
https://github.com/drocsid/cros-scripts/blob/c361371f37d1e298a3810fcc7b11a502043c56ef/cros_workon_make#L12
. I have tried modifying it to the top level directory that contains
./src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
but something from one of the other scripts seems to set it back.

13) There are also related GCLIENT_ROOT functions sprinkled around in
common.sh E.G. https://github.com/drocsid/cros-scripts/blob/main/common.sh#L265

Then I'm trying to determine why GCLIENT_ROOT is not set properly on
bullseye, and also trying to figure out a way to override it if I
can't fix the scripts directly.




On Thu, Aug 5, 2021 at 6:04 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
>
> Hi,
>
> > Can someone tell me where I should look for the kernel for the
> > loopback setting?
>
> Quite exactly a year ago i learned the hard way that it's
> CONFIG_BLK_DEV_LOOP which on amd64 should be set to "m" to get /dev/loop*.
> See its description at
>   https://sources.debian.org/src/linux/5.10.46-1/drivers/block/Kconfig/#L174
>
> But i'm somewhat puzzled by this statement at the end
>   "Most users will answer N here."
>
> A code search yields no BLK_DEV_LOOP=n
>   https://codesearch.debian.net/search?q=package%3Alinux+BLK_DEV_LOOP%3Dn&literal=0
> but lots of "y" and "m".
>
> (Wasn't there a way to inquire the running kernel's configuration ?)
>
> -----------------------------------------------------------------------
>
> I see that tomas@tuxteam.de did not Cc you. In case you are not subscribed,
> i repeat what he wrote:
>
> > Could you please do a quick
> >  sudo losetup -a
> > and perhaps
> >   ls /dev/loop*
> > and tell us the result?
> > [...] Perhaps they are all used?
>
> Have a nice day :)
>
> Thomas
>

[toc] | [prev] | [next] | [standalone]

#238309

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 06, 2021 at 09:48:29PM -0700, Colin Williams wrote:
> Hello everyone,
> 
> In hindsight after looking at this much too late there were many
> mistakes in my initial mail. The issue may or may not be debian
> related and involves at least analyzing the script. There is a claim
> in the documentation that
> 
> Then I'll make another attempt to further expose my ignorance.

[...]

I've rather the impression that you are trying to kill too
many birds with one stone :)

And, to be honest, I don't feel like debugging some random script
off github :-)

Why don't you first try to find out whether (a) loopback is working
on your running machine and (b) not all of your available loopback
devices are exhausted?

I think I posted some proposals already here [1].

Cheers

[1] https://lists.debian.org/debian-user/2021/08/msg00248.html

-- t

[toc] | [prev] | [next] | [standalone]

#238310 — Re: losetup: cannot find an unused loop device , kernel config of loopback device

Hi,

Colin Williams wrote:
> http://ix.io/3v3i

At least this shows an impressive partition table.
(Among them 5 partitions of size 512 bytes.)


> http://ix.io/3v6K

(Best to be downloaded and viewed in a text editor.)


> I believe the issues arise in
> https://github.com/drocsid/cros-scripts/blob/main/common.sh
> [...]
> +++ sudo losetup --show -f
> /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chrom
> iumos_base_image.bin
> losetup: cannot find an unused loop device

According to the man page this aims for acquiring an existing but unused
loop device. But in my local experiments it also creates a new loop device
if all existing ones are occupied.
So this should work if new loop devices can be created at all.


> 10) The path
> /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
> does not exist

But

  sudo losetup --show -f non_existing_file_name

yields

  losetup: non_existing_file_name: failed to set up loop device: No such file or directory

and not "cannot find an unused loop device".


So currently i think that at your point 10 your investigation left the road
to the loop device problem.

You should in any case look how many loop devices are occupied before
your script run:

  losetup -l -a

If this does not show a lot of devices, then you will have execute this
command at various places in the script in order to see how the list of
used loop devices evolves during the script run.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#238312

Hi Thomas,

It's not entirely clear that what I was trying to express was
understood. Then in short:

1) A file ./src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
is created

2) It seems that commands use a variable called GCLIENT_ROOT and it's
value is set to /mnt/host/src

3) When trying to create the loopback device the script tries to use a
path /mnt/host/src/rc/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
which does not exist

4) I'm stuck trying to figure out why GCLIENT_ROOT can't be set to the
actual mounted filesystem path so that the image can be found and the
loopback device created, etc.

Then I assume I could create a block device use losetup with the
correct path. So I'm debugging the script. There may be some details
related to chroot and GCLIENT_ROOT that I don't understand. Let me
know if I need to re-read your email.

Best Regards

On Sat, Aug 7, 2021 at 12:43 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
>
> Hi,
>
> Colin Williams wrote:
> > http://ix.io/3v3i
>
> At least this shows an impressive partition table.
> (Among them 5 partitions of size 512 bytes.)
>
>
> > http://ix.io/3v6K
>
> (Best to be downloaded and viewed in a text editor.)
>
>
> > I believe the issues arise in
> > https://github.com/drocsid/cros-scripts/blob/main/common.sh
> > [...]
> > +++ sudo losetup --show -f
> > /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chrom
> > iumos_base_image.bin
> > losetup: cannot find an unused loop device
>
> According to the man page this aims for acquiring an existing but unused
> loop device. But in my local experiments it also creates a new loop device
> if all existing ones are occupied.
> So this should work if new loop devices can be created at all.
>
>
> > 10) The path
> > /mnt/host/source/src/build/images/kukui/R94-14125.0.2021_08_05_1510-a1/chromiumos_base_image.bin
> > does not exist
>
> But
>
>   sudo losetup --show -f non_existing_file_name
>
> yields
>
>   losetup: non_existing_file_name: failed to set up loop device: No such file or directory
>
> and not "cannot find an unused loop device".
>
>
> So currently i think that at your point 10 your investigation left the road
> to the loop device problem.
>
> You should in any case look how many loop devices are occupied before
> your script run:
>
>   losetup -l -a
>
> If this does not show a lot of devices, then you will have execute this
> command at various places in the script in order to see how the list of
> used loop devices evolves during the script run.
>
>
> Have a nice day :)
>
> Thomas
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web