Date: Tue, 24 Aug 2004 00:00:47 GMT From: "fbsd_user" <fbsd_user@a1poweruser.com> To: freebsd-bugs@FreeBSD.org Subject: RE: kern/70880: 5.3 beta1 nfs problem Message-ID: <200408240000.i7O00lhU068662@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/70880; it has been noted by GNATS. From: "fbsd_user" <fbsd_user@a1poweruser.com> To: "Ceri Davies" <ceri@submonkey.net> Cc: <freebsd-gnats-submit@FreeBSD.org> Subject: RE: kern/70880: 5.3 beta1 nfs problem Date: Mon, 23 Aug 2004 19:54:31 -0400 Ceri wrote: > On Mon, Aug 23, 2004 at 07:58:20PM +0000, Joe wrote: > >> Downloaded 5.3 beta1-i386-mininstall.iso, ran md5 checksum and count >> matched, burned to cd and installed using standard/kern-dev. >> Answered no to both nfs option questions. On first boot nfs server >> is started. ps ax command shows nfsiod1, nfsiod2, and nfsiod3 tasks >> running. /etc/rc.conf does not have any nsf override statements. >> Only way to get rid of nfs is to comment out nfs statements in >> kernel source and recompile kernel. This is an error that needs >> fixing. > > nfsiod is a NFS client-side process. In this instance they are kernel > threads and you can turn them off if you like by adding > vfs.nfs.iodmin=0 to /etc/sysctl.conf, or by removing the NFSCLIENT > option from your kernel configuration. > > I have changed the Severity of this PR to something more realistic. > > Ceri Ceri Thanks for the work around info, But that's not the point of this bug report. In case you missed the meaning: there should not be any nfs anything running on a clean install when the sysinstall questions to enable nfs are answered as no. This is not something that has ever been part of past stable releases so it must be turned on in the kernel by mistake. The release built team must build a true kernel.generic module which has kernel debugging and nfs kernel options turned off. Creating a stable 5.3 release is my understanding of the goal of the 5.3 beta weekly build series. Reports of these kinds of bugs get a high severity so they get fixed by next weeks build so why would you change this PR's Severity? If anything you should have directed this PR to the leader of the release build team so they can address this bug by next Fridays build. Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408240000.i7O00lhU068662>