From owner-freebsd-current Fri Feb 5 13:23:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA04466 for freebsd-current-outgoing; Fri, 5 Feb 1999 13:23:37 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from liquid.tpb.net (drum-n-bass.party-animals.com [194.134.94.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA04458 for ; Fri, 5 Feb 1999 13:23:32 -0800 (PST) (envelope-from niels@bakker.net) Received: from localhost (niels@localhost) by liquid.tpb.net (8.9.1a/8.8.8/Debian/GNU) with SMTP id WAA18561; Fri, 5 Feb 1999 22:23:09 +0100 Date: Fri, 5 Feb 1999 22:23:08 +0100 (CET) From: N To: Matthew Dillon cc: current@FreeBSD.ORG Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr In-Reply-To: <199902051947.LAA98698@apollo.backplane.com> Message-ID: <990205221457.18464A-100000@liquid.tpb.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Matt Dillon: [make world over nfs breakage] > It is very odd. I don't suppose very many people try to make install > over NFS ( it works, you just have to chflags -R noschg the destination > on the NFS server before you run make install on the NFS client ). Actually, I did, this broke somewhere at the end of January in 3.0-STABLE. Unfortunately I first built a kernel, rebooted with that, and tried to build the world, but /usr/bin/ps was the wrong version so I couldn't easily see where processes were hanging. (Can you say Catch-22 - downgrade kernel so ps works but the bug didn't expose itself.) A kernel from Jan 27 works, but one dated Feb 2 doesn't. Symptoms include a "hanging" in a random command, be it cc or install. ^Z / fg doesn't work. /usr/src and /usr/obj both mounted via NFS. I resolved the issue by keeping /usr/obj local (with -DNOGAMES -DNOINFO this remained just under 200 MB which was basically what I have available). Since it's quite irritating to find a hanging build process in the morning (a '486 is a terrible thing to waste, isn't it? :) I didn't peruse it any further. If anyone can point me at documentation on how to configure the diuerse boot loaders that stuff gets sent to a serial port during booting, a kernel debugger is available (either via console or serial port) but reboots after panics still happen without user intervention I'd be happy to try to reproduce this. On a totally unrelated note, su(1) never works if you're not in group wheel, Kerberos or no Kerberos, as far as I can tell. -- Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message