[BusyBox 0000609]: losetup not working

bugs at busybox.net bugs at busybox.net
Wed Feb 22 16:43:06 UTC 2006


The following issue has been CLOSED 
====================================================================== 
http://busybox.net/bugs/view.php?id=609 
====================================================================== 
Reported By:                bcornec
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   609
Category:                   Other
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Resolution:                 not fixable
Fixed in Version:           
====================================================================== 
Date Submitted:             12-20-2005 05:31 PST
Last Modified:              02-22-2006 08:43 PST
====================================================================== 
Summary:                    losetup not working
Description: 
Hello,

It seems I'm unable to have a working losetup inside my busybox.
I'm trying to mount an iso image through NFS from a busybox env launched
from PXE.

I've read http://bugs.uclibc.org/view.php?id=498  and thought I found
the issue, so I desactivated devfs, but it doesn't help.

I tried 1.01, 1.1-pre, svn version, and they all fail in a different
way:

1.01: NFS mount doesn't work :-( so I can't have access to my iso image.
But as 1.10 has some interesting features for my project, I'd prefer to
use it.

With 1.1.0-pre1 or SVN: 

# losetup /dev/loop7 /tmp/isodir/rhel3-1.iso
losetup /dev/loop7: Invalid argument

Kernel is a RHEL 3 one (2.4.21 based), loop module is loaded and attached
is my .config:

Any hint would be welcome.


====================================================================== 

---------------------------------------------------------------------- 
 bcornec - 12-21-05 03:00  
---------------------------------------------------------------------- 
A colleague using my tool has reported that it works without issue on a
RHEL4 so it could be a problem uniquely on a 2.4 based kernel. 

---------------------------------------------------------------------- 
 landley - 01-08-06 19:29  
---------------------------------------------------------------------- 
Huh.  Since svn 12582 went in Nov 29 and this bug was created Dec 20 and
you say you tried current svn, I'm assuming that didn't fix it for you. 
Despite this, I just re-checked losetup and it's working for me.  More
info?

Similarly, svn 11289 fixing NFS mount went in at the end of October, and
it worked for _somebody_...
 

---------------------------------------------------------------------- 
 bcornec - 01-11-06 07:46  
---------------------------------------------------------------------- 
Hello,

Sorry for the delay, I had other bugs as well to catch on my side :-)

I think I'm able to reproduce it and give you a way to reproduce it.

More context: I'm using busybox as a boot environment.

If I test it from my current environment (rhel3) it's working without
issue:

[root at localhost chroot]# mount 10.3.3.72:/writer/nfs /mnt/cdrom
[root at localhost chroot]# ll /mnt/cdrom
total 602668
-rw-r--r--    1 root     nobody   616525824 Mar 25  2004 1.iso
[root at localhost chroot]# losetup /dev/loop7  /mnt/cdrom/1.iso
[root at localhost chroot]# mount -t iso9660 /dev/loop7 /mnt/fs

Then I have access to the content of the CD.


So I tried to recreate a chroot in order to test it.

I created  links in that chroot to all busybox commands to the latest
busybox binary of today, created /dev/loop7 (mknod /dev/loop7 b 7 7),
mounted my NFS server in the chroot (mount 10.3.3.72:/writer/nfs
/mnt/cdrom)

And then:
# losetup /dev/loop7 /mnt/fs/1.iso
losetup: /dev/loop7: Invalid argument

I invoked it from outside using strace:
strace  chroot /tmp/chroot losetup /dev/loop7  /mnt/fs/1.iso

[...]
open("/mnt/fs/1.iso", O_RDWR|O_LARGEFILE) = 3
stat64("/dev/loop7", {st_mode=S_IFBLK|0644, st_rdev=makedev(7, 7), ...}) =
0
open("/dev/loop7", O_RDWR|O_LARGEFILE)  = 4
ioctl(4, 0x4c05, 0xbfffcec8)            = -1 EINVAL (Invalid argument)
close(4)                                = 0
close(3)                                = 0
write(2, "losetup: ", 9losetup: )                = 9
write(2, "/dev/loop7", 10/dev/loop7)              = 10
write(2, ": Invalid argument\n", 19: Invalid argument
)    = 19
exit_group(1)                           = ?

I wonder whether the O_RDWR flags are correct ?

Now that I can reproduce it easier and that I'm able to use strace, I can
debug much more easily, so wait for your advises on what to do next.

Many thanks for your support on this.
Bruno. 

---------------------------------------------------------------------- 
 vodz - 01-26-06 04:26  
---------------------------------------------------------------------- 
I think, ioctl(fd, LOOP_*, ...) is not acceptable over NFS. 

---------------------------------------------------------------------- 
 landley - 02-20-06 10:31  
---------------------------------------------------------------------- 
Vodz: I just did an losetup on an NFS mounted root filesystem and it worked
just fine, so your theory is wrong. 

---------------------------------------------------------------------- 
 vodz - 02-21-06 01:09  
---------------------------------------------------------------------- 
> Vodz: I just did an losetup on an NFS mounted root filesystem and it
worked just fine, so your theory is wrong. 

Hmm. You can`t reproduce this bug? Strange... 

---------------------------------------------------------------------- 
 bcornec - 02-21-06 02:03  
---------------------------------------------------------------------- 
>From the last test I made:

With a 2.6 kernel adding a -o ro on the mount line to the -o loop doesn't
show the problem anymore (I mount an ISO image of a CD through NFS) and
the mount succeeds
With a 2.4 kernel adding a -o ro on the mount line to the -o loop doesn't
change anything and the error occurs (mount doesn't work) 

---------------------------------------------------------------------- 
 landley - 02-21-06 13:00  
---------------------------------------------------------------------- 
I tested on 2.6.

If losetup fails, the current mount code should retry read only, although
it's possible NFS is giving the wrong error so the fallback behavior isn't
occurring.  (I did losetup by hand from the command line and then mounted
the loop device.  I didn't check if it was writeable.)

I'm not sure I can do much about 2.4.  It's possible that Vodz is right
for that one, loopback on nfs smells like something 2.4 just didn't
support.

Let's see, ssh over to the PPC machine with an NFS root partition:

./busybox mount
(null) on / type nfs
(rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=192.168.92.2)

And a few others but none of them at /

dd if=/dev/zero of=woot.img bs=4096 count=4096
./busybox mke2fs woot.img
./busybox losetup /dev/loop0 woot.img
./busybox mount /dev/loop0 scripts
echo hello > scripts/thingy
cat scripts/thingy
./busybox umount scripts
./busybox mount woot.img scripts

Confirmed: it's a fully read/write mount on an NFS root partition.  Kernel
version 2.6.10-timesys.1

(Yes, busybox mount autodetects when to use loop devices. :)

I haven't got a 2.4 system with NFS hooked up to it, but if it doesn't
work there and does work on 2.6 (which it's doing for me), I'd say it's a
kernel issue.

Are you willing to call this a 2.4 kernel issue and let us close the bug? 

---------------------------------------------------------------------- 
 bcornec - 02-22-06 07:01  
---------------------------------------------------------------------- 
No problem on my side to close the bug. At least that bug report remains
available for those interested.

Maybe a short note somewhere in the docuementation could be added to avoid
disappointments with the 2.4 ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-20-05 05:31  bcornec        New Issue                                    
12-20-05 05:31  bcornec        Status                   new => assigned     
12-20-05 05:31  bcornec        Assigned To               => BusyBox         
12-20-05 05:31  bcornec        File Added: .config                          
12-21-05 03:00  bcornec        Note Added: 0000804                          
01-08-06 19:29  landley        Note Added: 0000877                          
01-08-06 19:29  landley        Status                   assigned => feedback
01-11-06 07:46  bcornec        Note Added: 0000925                          
01-26-06 04:26  vodz           Note Added: 0001010                          
01-26-06 04:26  vodz           Status                   feedback => acknowledged
01-26-06 04:26  vodz           Resolution               open => not fixable 
02-20-06 10:31  landley        Note Added: 0001123                          
02-21-06 01:09  vodz           Note Added: 0001135                          
02-21-06 02:03  bcornec        Note Added: 0001136                          
02-21-06 13:00  landley        Note Added: 0001138                          
02-22-06 07:01  bcornec        Note Added: 0001144                          
02-22-06 08:43  landley        Status                   acknowledged => closed
======================================================================




More information about the busybox-cvs mailing list