[Problem] 7390: NFS mount bringt "Value too large for defined data type" bei ls ?

DrYes

Neuer User
Mitglied seit
21 Apr 2008
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo,

habe vergeblich versucht die letzten Tage meine alte NAS (ALL6200) via NFS bei einer gefreetzen 7390 (Firmware-Version 84.05.05freetz-devel-7725M) zu mounten. Das Mount Kommando wird so ansich auch angenommen:

Code:
[email protected]:/# mount -t nfs -o soft nas:/mnt/data /var/tmp/mnt/
[email protected]:/# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
tmpfs on /var type tmpfs (rw)
dev on /dev type tmpfs (rw,nosuid)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,mode=600)
/var/dev/nand on /var/media/ftp type yaffs2 (rw,sync)
usbfs on /proc/bus/usb type usbfs (rw)
nas:/mnt/data on /var/tmp/mnt type nfs (rw,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nointr,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.168.0.50)
[email protected]:/#
[email protected]:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                13.3M     13.3M         0 100% /
tmpfs                    56.7M      1.3M     55.4M   2% /var
dev                      56.7M     16.0K     56.6M   0% /dev
/var/dev/nand           512.0M      1.6M    510.4M   0% /var/media/ftp
nas:/mnt/data           230.1G    173.0G     57.1G  75% /var/tmp/mnt
[email protected]:/#
[COLOR="red"][email protected]:/# ls -l /var/tmp/mnt/
ls: can't open '/var/tmp/mnt/': Value too large for defined data type[/COLOR]
[email protected]:/#
[email protected]:/#
[email protected]:/#
[email protected]:/# strace -v ls /var/tmp/mnt/
execve("/bin/ls", ["ls", "/var/tmp/mnt/"], ["CONFIG_WLAN=y", 
[......]
"HWSubRevision=3"]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aaad000
open("/usr/lib/freetz/libc.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/mod/lib/libc.so.0", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_dev=makedev(31, 0), st_ino=1015, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=1266, st_size=647968, st_atime=2011/10/03-01:51:18, st_mtime=2011/10/03-01:51:18, st_ctime=2011/10/03-01:51:18}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aaae000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\256\220\0\0\0004\0"..., 4096) = 4096
old_mmap(NULL, 737280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aabe000
old_mmap(0x2aabe000, 641648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2aabe000
old_mmap(0x2ab6a000, 7952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9c000) = 0x2ab6a000
old_mmap(0x2ab6c000, 21872, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ab6c000
close(3)                                = 0
munmap(0x2aaae000, 4096)                = 0
stat("/lib/ld-uClibc.so.0", {st_dev=makedev(31, 0), st_ino=1039, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=43, st_size=21528, st_atime=2011/10/03-01:51:18, st_mtime=2011/10/03-01:51:18, st_ctime=2011/10/03-01:51:18}) = 0
mprotect(0x2ab6a000, 4096, PROT_READ)   = 0
mprotect(0x2aabc000, 4096, PROT_READ)   = 0
ioctl(0, TIOCNXCL, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0xb3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x01\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x04\x00\x00\x00\x00\x00\x00"}) = 0
ioctl(1, TIOCNXCL, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0xb3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x01\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x04\x00\x00\x00\x00\x00\x00"}) = 0
getuid()                                = 0
time([1317655412])                      = 1317655412
ioctl(0, 0x40087468, 0x7f93c0ac)        = 0
ioctl(1, TIOCNXCL, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0xb3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x01\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x04\x00\x00\x00\x00\x00\x00"}) = 0
ioctl(1, TIOCNXCL, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0xb3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x01\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x04\x00\x00\x00\x00\x00\x00"}) = 0
stat64(0x7f93cc44, 0x7f93bf88)          = 0
brk(0)                                  = 0x494000
brk(0x495000)                           = 0x495000
open("/var/tmp/mnt/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, 0x7f93bef8)                    = -1 EOVERFLOW (Value too large for defined data type)
close(3)                                = 0
brk(0x496000)                           = 0x496000
brk(0x497000)                           = 0x497000
write(2, "ls: can't open '/var/tmp/mnt/': V"..., 70ls: can't open '/var/tmp/mnt/': Value too large for defined data type
) = 70
exit(1)                                 = ?
[email protected]:/#
Allerdings scheitert es an einem ls dann mit dem Fehler "ls: can't open '/var/tmp/mnt/': Value too large for defined data type". Ein direkter Zugriff auf eine Datei im mount funktioniert allerdings anscheinend (.z.b. "cat ../text.txt).

Mit meinem alten SpeedPort W701V (7170 freetz mit replaced kernel) hat soweit alles wunderbar funktioniert.

Die "Replace Kernel" Option hat bei meiner 7390 zu einer Reboot-Schleife geführt, sobald es zu ADSL Sync / Online gekommen ist. However, DSL kurzzeitig abgestellt um den mount zu testen hat genau das selbe ausgespuckt.

Bin mit meinem Latein am Ende und würde mich wirklich über jegliche Hilfe freuen.

Gruß,
DrYes.
 

markuschen

Mitglied
Mitglied seit
23 Okt 2005
Beiträge
370
Punkte für Reaktionen
0
Punkte
16
"Replace Kernel" funktioniert nur, wenn du chronyd entfernst (unter patche).
 

DrYes

Neuer User
Mitglied seit
21 Apr 2008
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo markuschen,
Vielen Dank. Das nehme ich so mal auf...
Wie erwähnt, das nfs mount verhalten ist beim replaced Kernel identisch.
 

Zurzeit aktive Besucher

3CX

Statistik des Forums

Themen
235,914
Beiträge
2,067,826
Mitglieder
356,955
Neuestes Mitglied
LiamDobczinski