From owner-freebsd-questions@FreeBSD.ORG Thu Jan 29 19:21:15 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 794C7106564A for ; Thu, 29 Jan 2009 19:21:15 +0000 (UTC) (envelope-from arjan.van.der.oest@worldmax.nl) Received: from worldmax.nl (mail.worldmax.nl [81.28.80.135]) by mx1.freebsd.org (Postfix) with ESMTP id CABE08FC23 for ; Thu, 29 Jan 2009 19:21:14 +0000 (UTC) (envelope-from arjan.van.der.oest@worldmax.nl) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3959 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Importance: normal Priority: normal Date: Thu, 29 Jan 2009 20:21:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [7.1-RELEASE-p2 amd64] NFS mount in fstab hangs duringmountcritremote execution Thread-Index: AcmB9qVh7HPEaN14Tdat/BTlvsm3WgAT5GvA References: From: "Arjan van der Oest" To: Subject: RE: [7.1-RELEASE-p2 amd64] NFS mount in fstab hangs duringmountcritremote execution X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 19:21:15 -0000 To make it even stranger, a new fresh installed box has no problems with = this configuration. The difference between these two : on the problem = box I enabled NFS client during installation with sysinstall, on the = working box I've just added the nfs_client_enable=3D"YES" flag manually = to rc.conf. I would suspect that the sysinstall approach would do the same (as it = looks like it) but now I suspect sysinstall does something else too that = breaks the config. --=20 Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. =20 Arjan van der Oest Network Design Engineer =20 T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 =20 E.: arjan.van.der.oest@worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78) fingerprint: 2E9F = 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78 -----Original Message----- From: owner-freebsd-questions@freebsd.org = [mailto:owner-freebsd-questions@freebsd.org] On Behalf Of Arjan van der = Oest Sent: donderdag 29 januari 2009 10:48 To: freebsd-questions@freebsd.org Subject: [7.1-RELEASE-p2 amd64] NFS mount in fstab hangs = duringmountcritremote execution Hi, I=E2=80=99m puzzled and either I don=E2=80=99t understand the boot rc.d = process or there is something wrong with it =E2=98=BA I have this 7.1-RELEASE-p2 amd64 machine compiled with a GENERIC kernel, = so NFS support is baked right into the kernel by default. In fsstab I = have this entry: :/data/nfs-shares/S1018SR18 /nfs-mounts/backupsrv = nfs rw 0 0 Further, as per the handbook, I=E2=80=99ve set nfs_client_enable to = =E2=80=9CYES=E2=80=9D in the rc.conf. During boottime the machine hangs = on the console after stating =E2=80=9CMounting NFS = filesystems:=E2=80=9D. I notice that _immediately_ after that line there = is a console message saying =E2=80=9Cem0: link state changed to = UP=E2=80=9D. Then the system repeats this line until eternity (well, the = max I=E2=80=99ve been waiting has been 30 minutes), no . appears = indicating the system has not yet completed the 'mount -a 't nfs' = command from the mountcritremote script. [udp] :/data/nfs-shares/S1018SR18: RPGPROC_MNT: RPC: = Timed out Hitting CTRL-C forces the machine to continue the boot process, aborting = the mountcritremote script. What strikes me is that the actual NFS share = has been mounted, although the boot-process seems to indicate = otherwise... After doing a umount and mount =E2=80=93a =E2=80=93t nfs = again the machine has no problem whatsoever. Something else that puzzles me, when I set the = nfs_client_enable=3D=E2=80=9DNO=E2=80=9D line in the rc.conf, the same = happens : console hangs on the mountcritremote script until I hit CTRL-C = and after that the share has been mounted anyway? Shouldn=E2=80=99t the = machine ignore nfs filesystems with this rc.conf config?=20 I=E2=80=99ve removed the entry in fstab and set a line in rc.local and = then the boot-process works fine without interruption.=20 So I'm currently lost with these questions: - why does the system tries to mount the nfs filesystem from the fstab = while nfs_client_enable has been set to no in rc.conf? - why does the system seems to hang on the mountcritremote script = although there seems no valid reason for that. I can imagine the network = has not been fully configured yet when executing (indicated by the link = UP message right after the mouning NFS filesystems line) but why will = the script not continue after a few timeouts? And more bizarre: when = interrupting the mountcritremote script the share has been actually = mounted, so it seems the 'mount -a -t nfs' command has actually been = executed successfully. Any fingerpoints? --=20 Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. =20 Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 =20 GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F = 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) No virus found in this incoming message. Checked by AVG - http://www.avg.com=20 Version: 8.0.176 / Virus Database: 270.10.15/1921 - Release Date: = 1/28/2009 6:37 AM Internet communications are not secure; therefore, the integrity of this = e-mail cannot be guaranteed following transmission on the Internet. This = e-mail may contain confidential information. If you have received this = e-mail in error, please notify the sender and erase this e-mail. Use of = this e-mail by any person other than the addressee is strictly = forbidden. This e-mail is believed to be free of any virus that might = adversely affect the addressee's computer system; however, no = responsibility is accepted for any loss or damage arising in any way = from its use. All the preceding disclaimers also apply to any possible = attachments to this e-mail.