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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
