[Lunar-bugs] [bug] netmount fails to mount nfs at boottime regularly
Lunar bug reports list
lunar-bugs at lunar-linux.org
Fri Jun 3 09:48:52 UTC 2005
Project: lunar-linux
ID:
Version: <none>
Component: init.d (daemon scripts)
Category: bug reports
Priority: minor
-Assigned to: <unassigned>
+Assigned to: sofar
Reported by: remsys
Updated by: sofar
-Status: won't fix
+Status: active
This is an inherent problem with some devices that should be addressed
by the networking init script. In all cases it should be possible to
add a 'timeout' to the network script that waits a little bit (5
seconds) and does some form of checking if the network device is
actually up or not (ifconfig $DEVICE | grep -qw UP ?). This needs to be
investigated.
sofar
Previous comments:
------------------------------------------------------------------------
Sat, 03/12/2005 - 10:17 : remsys
My lunar-workstation fails to mount nfs-exports from my lunar-server
regularly. Doing a /etc/init.d/netmount start afterwards mounts the
exports without any problems.
There's no errormessage during boot, just [failed] behind "Mounting
network shares:"
I think the exports get mounted at boottime once in every 5 boots, so
that's in 20% of the cases and it annoys the **** out of me that I
haven't been able to fix it...
My other (Mandrake)workstation mounts the exports flawlessly, so my
guess is there is something wrong in the setup of my workstation.
Some versions and configs on these systems:
- kernel 2.4.28-lunar (both server and ws)
- nfs kernel config:
root at ws-remco /etc/lunar/local # cat .config | grep -i nfs
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_ACL is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_ACL is not set
CONFIG_NFSD_TCP=y
# CONFIG_NCPFS_NFS_NS is not set
- /etc/exports on server:
root at server-home /etc # cat exports
/mnt/data 192.168.1.3(rw,sync) 192.168.1.4(rw,sync)
/mnt/fotoos 192.168.1.3(rw,sync) 192.168.1.4(rw,sync)
/mnt/mp3 192.168.1.3(rw,sync) 192.168.1.4(rw,sync)
- /etc/fstab on ws:
root at ws-remco /etc # cat fstab | grep nfs
192.168.1.2:/mnt/fotoos /mnt/fotoos nfs rw,hard,intr
0 0
192.168.1.2:/mnt/mp3 /mnt/mp3 nfs rw,hard,intr
0 0
192.168.1.2:/mnt/data /mnt/data nfs rw,hard,intr
0 0
- The server gets booted in runlevel 3:
root at server-home ~ # ls /etc/rc3.d/
S10network
S12klogd
S14nfslock
S31ntpd
S80postfix
S81ulogd
S90cupsd
S11portmap
S12syslogd
S25shorewall
S60nfs
S80sshd
S90crond
s90mysqld
- the ws runs in runlevel 5:
root at ws-remco ~ # ls /etc/rc5.d/
K85httpd
S12klogd
S14nfslock
S80postfix
S90cupsd
S10network
S12syslogd
S15netmount
S80sshd
S90mysqld
S11portmap
S12ulogd
S31ntpd
S90crond
S95gdm
netmount is the latest version:
root at ws-remco ~ # lvu installed moonbase 20050312.09
root at ws-remco ~ # diff /etc/init.d/netmount
/var/lib/lunar/moonbase/net/net-tools/init.d/netmount
root at ws-remco ~ #
I'm lost :?
------------------------------------------------------------------------
Tue, 03/15/2005 - 10:29 : Moe
Would you mind using the pastebot to give us a cleaner output of what
you posted earlier?
PS: Pastebot: http://thing.fwsystems.com:8889/
------------------------------------------------------------------------
Thu, 03/17/2005 - 15:47 : sofar
* since the issue is randomly occurring, I think there might be other
problems involved than just the kernel config
* there is a new network script out, please give that a try too
* do you run NIS or dhcp? this might make the network device take
longer to initialize, causing this. I am troubled by this at work where
my NIS server sometimes doesn't work on boot... A reboot often fixes it.
------------------------------------------------------------------------
Fri, 06/03/2005 - 08:06 : remsys
Using kernel 2.4.31 brought new messages to light during bootup:
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.30.
eth0: forcedeth.c: subsystem: 01695:1000 bound to 00:04.0
eth0: no link during initialization.
Before the message 'eth0: link up.' appears, netmount has already
started initialization, so my guess now is, that this is driver
related, rather than a Lunar-related issue.
Sorry for the bogus-report :(
--
View: http://lunar-linux.org/?q=node/view/753
Edit: http://lunar-linux.org/?q=project/comments/add/753
More information about the Lunar-bugs
mailing list