Date: Sun, 13 Jun 2010 07:38:53 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Dmitry Pryanishnikov <lynx.ripe@gmail.com>, freebsd-stable@freebsd.org Subject: Re: nfsv4_server_enable="YES": link_elf: symbol svcpool_destroy undefined Message-ID: <20100613043853.GR13238@deviant.kiev.zoral.com.ua> In-Reply-To: <Pine.GSO.4.63.1006122202001.19368@muncher.cs.uoguelph.ca> References: <AANLkTincroPx6osLDjY3EH4qW71H2ABq0lXQLKORpPOg@mail.gmail.com> <Pine.GSO.4.63.1006122202001.19368@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--6eUvXotnMb6+obQB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 12, 2010 at 10:08:31PM -0400, Rick Macklem wrote: >=20 >=20 > On Sun, 13 Jun 2010, Dmitry Pryanishnikov wrote: >=20 > >Hello! > > > > I'm trying to start the experimental NFSv4 server in RELENG_8 w/o > >building it into the kernel, as nfsv4(4) suggests: > > > >... or start mountd(8) and nfsd(8) with the ``-e'' option to force use o= f=20 > >the > > experimental server. The nfsuserd(8) daemon must also be running. = =20 > > This > > will occur if > > > > nfs_server_enable=3D"YES" > > nfsv4_server_enable=3D"YES" > > nfsuserd_enable=3D"YES" > > > > are set in rc.conf(5). > > > >However, mountd fails to start nfsd; the same problem exists when > >doing it by hands: "kldload nfsd" gives > > > >kernel: link_elf: symbol svcpool_destroy undefined > > > >error. Can this problem be solved w/o building kernel with "options NFSD= "? > > > Well, if you build a kernel with any of the options that cause "krpc" > to be compiled into the kernel, it works. (I usually test with a GENERIC > kernel that has NFSCLIENT and NFSSERVER defined in it, so nfsd.ko loads > fine.) >=20 > Basically "nfsd" is defined as dependent on "nfscommon", then > "nfscommon" is defined as dependent on "krpc" and "nfssvc". This > gets everthing to load, but when it tries to load "nfsd.ko", it > can't find the symbols in "krpc.ko" or "nfssvc.ko" if they weren't > linked into the kernel. >=20 > For example, here's what I saw: > nfsv4-laptop# kldstat > Id Refs Address Size Name > 1 12 0xc0400000 d1f338 kernel > 4 1 0xc2eff000 1e000 nfsclient.ko > 5 1 0xc2ea9000 2000 nfs_common.ko > 6 2 0xc2f1d000 15000 krpc.ko > 11 1 0xc2fe3000 16000 nfscommon.ko > 12 1 0xc2fc5000 2000 nfssvc.ko > nfsv4-laptop# nm /boot/nkernel/krpc.ko | fgrep svcpool > 0000cdf0 t svcpool_active > 0000de40 t svcpool_create > 0000e590 t svcpool_destroy > 0000e1d0 t svcpool_maxthread_sysctl > 0000e2b0 t svcpool_minthread_sysctl >=20 > and "nfsd" wouldn't load because it couldn't find "svcpool_destroy", > just like you saw. >=20 > If you apply this patch and rebuild the module, it will find the > symbols. (Is that what is supposed to happen or is something broken?) >=20 > --- fs/nfsserver/nfs_nfsdport.c.sav 2010-06-12 20:27:53.000000000 -0400 > +++ fs/nfsserver/nfs_nfsdport.c 2010-06-12 20:37:09.000000000 -0400 > @@ -3147,4 +3147,6 @@ > MODULE_VERSION(nfsd, 1); > MODULE_DEPEND(nfsd, nfscommon, 1, 1, 1); > MODULE_DEPEND(nfsd, nfslockd, 1, 1, 1); > +MODULE_DEPEND(nfsd, krpc, 1, 1, 1); > +MODULE_DEPEND(nfsd, nfssvc, 1, 1, 1); I think the patch is right, this is how symbol resolution is supposed to work. --6eUvXotnMb6+obQB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwUYNwACgkQC3+MBN1Mb4gNhgCfXc2SCgPEZTxtdAYgOm3oDiN5 QgcAoIAhG9fYLCaXtxAoDKTwzSwJccE+ =ELpO -----END PGP SIGNATURE----- --6eUvXotnMb6+obQB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100613043853.GR13238>