From owner-freebsd-bugs Wed Oct 4 23:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 82EF437B503 for ; Wed, 4 Oct 2000 23:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA30130; Wed, 4 Oct 2000 23:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 4 Oct 2000 23:20:02 -0700 (PDT) Message-Id: <200010050620.XAA30130@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Peter Pentchev Subject: Re: kern/21753: Proc size mismatch Reply-To: Peter Pentchev Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21753; it has been noted by GNATS. From: Peter Pentchev To: achilov@granch.ru Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/21753: Proc size mismatch Date: Thu, 5 Oct 2000 09:11:36 +0300 On Thu, Oct 05, 2000 at 12:58:29PM +0700, Rashid N. Achilov wrote: > Peter Pentchev wrote: > > > > On Wed, Oct 04, 2000 at 06:58:49PM +0700, System Administartor wrote: > > > >Synopsis: Proc size mismatch > > [snip] > > > > > > >Description: > > > > > > After install new kernel, which was CVSed recently, at 30 Sep 2000, > > > ps says "Proc size mismatch (32736 total, 1048 chunks)" > > > > > > >Fix: > > > > > > Return to 4.1-RELEASE kernel code > > > > Wrong. > > Right. At least for me :-) When I saw it, I got very surprised, and > reboot from 4.1-RELEASE kernel fix this problem... This is a workaround, not a fix. A workaround, as in it lets you continue with your *old* binaries and your *old* kernel, which of course are in sync. It does not 'fix' the problem as in let you make use of the new features introduced in FreeBSD with the changes. > > > > Always upgrade your whole system when upgrading your kernel - > > there are almost certain to be changes in the system programs > > as well, especially if some important kernel structures have > > changed. > > > > I *REALLY* need rebuild hundred of there binaries, many of them didn't > change? Well, there is always make -DNOCLEAN buildworld, which leaves all of the /usr/obj tree intact (well, most of it, anyway :), and recompiles only the programs that have changed. If this should fail, then you must rebuild the whole thing - but this only happens very rarely, when major changes have been introduced. Ah, and yes, judging from personal experience, it's better to run mergemaster *before* the world build, so it can update make.conf *and* the mtree files - this takes care of the case when a new directory has been introduced in the tree and the build falls over for lack of dependencies :) G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message