Notes |
(0000804)
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. |
| |
(0000877)
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_...
|
| |
(0000925)
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@localhost chroot]# mount 10.3.3.72:/writer/nfs /mnt/cdrom
[root@localhost chroot]# ll /mnt/cdrom
total 602668
-rw-r--r-- 1 root nobody 616525824 Mar 25 2004 1.iso
[root@localhost chroot]# losetup /dev/loop7 /mnt/cdrom/1.iso
[root@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. |
| |
(0001010)
vodz
01-26-06 04:26
|
I think, ioctl(fd, LOOP_*, ...) is not acceptable over NFS. |
| |
(0001123)
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. |
| |
(0001135)
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... |
| |
(0001136)
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) |
| |
(0001138)
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? |
| |
(0001144)
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 ? |
| |
.config [^] (14,472 bytes) 12-20-05 05:31 
