[BusyBox] Busybox-1.0-pre7: "Could not find a loop device"

[graeme.n.brown at bt.com ()]

I 'm putting together a small embedded Linux distro based on Buybox and uClibc.
Trying Busybox-1.0-pre7 I am having difficulties with /bin/mount of loop devices.
I get an error message "Could not find a spare loop device" when I try to load
a CRAMFS image from my startup script [which happens to be /etc/rc.d/rc.S]
with lines such as

<snip> ....
/bin/mount -t cramfs -o loop /volumes/usrbin.cfs /usr/bin
<snip>

I have searched the archives for previous reportings of this error message and I got
the idea this bug (?) had been fixed in 2002.

Is Busybox-1.0-pre7 thought to have the same problem? BTW I have /dev/loop1 ... /dev/loop12
device files in my /dev directory.

Any help, or fixes would be appreciated.

Graeme N Brown

[Rob Landley]

Post by graeme.n.brown at bt.com ()
I 'm putting together a small embedded Linux distro based on Buybox and
uClibc. Trying Busybox-1.0-pre7 I am having difficulties with /bin/mount of
loop devices. I get an error message "Could not find a spare loop device"
when I try to load a CRAMFS image from my startup script [which happens to
be /etc/rc.d/rc.S] with lines such as

The problem is that a real mtab says ",loop" in the fourth field, and when
/etc/mtab is a symlink to /proc/mounts the fourth field does NOT say this, so
umount doesn't know to do a losetup -d on the loop device. So it leaks loop
devices, and eventually run out. (Note: the original mount command does this
too, it just might take a while to notice.)

However, /proc/mounts DOES indicate what block device the mount is attached to
(/dev/loop5 or such, it's the first field), and presumably if we do losetup
-d on each one (or the relevant syscall) after unmount it, it'd silently fail
without doing any harm when it's not a loop device. (We could also check the
major/minor numbers to see if it's a loop device before doing the syscall,
but that's evil for a number of reasons and almost certainly unnecessary
work.)

I.E. mount needs a patch, which I've pondered doing for a while but haven't
gotten around to...

Ooh, hang on. Look at umount.c, line 179:

#if defined CONFIG_FEATURE_MOUNT_LOOP
if (freeLoop && blockDevice != NULL && !strncmp("/dev/loop", blockDevice,
9))
/* this was a loop device, delete it */
del_loop(blockDevice);
#endif

Figure out how to switch on CONFIGURE_FEATURE_MOUNT_LOOP and you should be
good. (Don't ask me what the business with freeLoop is, I don't know...)

Rob

[graeme.n.brown]

I 'm putting together a small embedded Linux distro based on Buybox and uClibc.
Trying Busybox-1.0-pre7 I am having difficulties with /bin/mount of loop devices.
I get an error message "Could not find a spare loop device" when I try to load
a CRAMFS image from my startup script [which happens to be /etc/rc.d/rc.S]
with lines such as

<snip> ....
/bin/mount -t cramfs -o loop /volumes/usrbin.cfs /usr/bin
<snip>

I have searched the archives for previous reportings of this error message and I got
the idea this bug (?) had been fixed in 2002.

Is Busybox-1.0-pre7 thought to have the same problem? BTW I have /dev/loop1 ... /dev/loop12
device files in my /dev directory.

Any help, or fixes would be appreciated.

Graeme N Brown

[Rob Landley]

Post by graeme.n.brown at bt.com ()
I 'm putting together a small embedded Linux distro based on Buybox and
uClibc. Trying Busybox-1.0-pre7 I am having difficulties with /bin/mount of
loop devices. I get an error message "Could not find a spare loop device"
when I try to load a CRAMFS image from my startup script [which happens to
be /etc/rc.d/rc.S] with lines such as

The problem is that a real mtab says ",loop" in the fourth field, and when
/etc/mtab is a symlink to /proc/mounts the fourth field does NOT say this, so
umount doesn't know to do a losetup -d on the loop device. So it leaks loop
devices, and eventually run out. (Note: the original mount command does this
too, it just might take a while to notice.)

However, /proc/mounts DOES indicate what block device the mount is attached to
(/dev/loop5 or such, it's the first field), and presumably if we do losetup
-d on each one (or the relevant syscall) after unmount it, it'd silently fail
without doing any harm when it's not a loop device. (We could also check the
major/minor numbers to see if it's a loop device before doing the syscall,
but that's evil for a number of reasons and almost certainly unnecessary
work.)

I.E. mount needs a patch, which I've pondered doing for a while but haven't
gotten around to...

Ooh, hang on. Look at umount.c, line 179:

#if defined CONFIG_FEATURE_MOUNT_LOOP
if (freeLoop && blockDevice != NULL && !strncmp("/dev/loop", blockDevice,
9))
/* this was a loop device, delete it */
del_loop(blockDevice);
#endif

Figure out how to switch on CONFIGURE_FEATURE_MOUNT_LOOP and you should be
good. (Don't ask me what the business with freeLoop is, I don't know...)

Rob