From owner-freebsd-stable@FreeBSD.ORG Fri Jan 20 09:03:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9245106566C for ; Fri, 20 Jan 2012 09:03:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 968A78FC0A for ; Fri, 20 Jan 2012 09:03:06 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id Pl361i0061swQuc5Al36Gw; Fri, 20 Jan 2012 09:03:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id Pl351i0131t3BNj3bl36q1; Fri, 20 Jan 2012 09:03:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 72245102C19; Fri, 20 Jan 2012 01:03:04 -0800 (PST) Date: Fri, 20 Jan 2012 01:03:04 -0800 From: Jeremy Chadwick To: Alexander Shikoff Message-ID: <20120120090304.GA90715@icarus.home.lan> References: <20120120071954.GA47009@crete.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120120071954.GA47009@crete.org.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 'make installworld' fails while upgrading from 9.0-CURRENT to 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 09:03:07 -0000 On Fri, Jan 20, 2012 at 09:19:54AM +0200, Alexander Shikoff wrote: > I'm unable to complete upgrading 9.0-CURRENT to 9.0-RELEASE from sources. > 'make installworld' fails on installing chpass: > [...] > ===> usr.bin/chpass (install) > install -s -o root -g wheel -m 4555 chpass /usr/bin > install -o root -g wheel -m 444 chpass.1.gz /usr/share/man/man1 > /usr/share/man/man1/chfn.1.gz -> /usr/share/man/man1/chpass.1.gz > /usr/share/man/man1/chsh.1.gz -> /usr/share/man/man1/chpass.1.gz > /usr/share/man/man1/ypchpass.1.gz -> /usr/share/man/man1/chpass.1.gz > /usr/share/man/man1/ypchfn.1.gz -> /usr/share/man/man1/chpass.1.gz > /usr/share/man/man1/ypchsh.1.gz -> /usr/share/man/man1/chpass.1.gz > /usr/bin/chfn -> /usr/bin/chpass > ln: /usr/bin/chfn: Operation not permitted > > It seems that it fails because of schg flag on old chfn, chsh, ypchpass, > ypchfn, ypchsh binaries. Should I manually remove it? Or there is > another way to fix an issue? Thanks in advance! Another person asked if you did installworld in single-user mode; very possible. You need to follow the instructions for rebuilding a system as documented in /usr/src/Makefile every single time you rebuild world/kernel (do not divert from the procedure). The procedure is preceded by the comment "For individuals wanting to upgrade their sources (even if only a delta of a few days)", around line 50 or so. If the system is remote and lacks serial console or remote KVM (e.g. you cannot boot single-user), then you're going to have to ask someone to do it for you, or make a trip to the datacenter. Another possibility is that you're using a kern.securelevel that isn't -1 (man security(7) and search for securelevel). Another possibility is that you might have "old cruft" (somehow) in your /usr/obj directory from the CURRENT/HEAD days. The procedure that has been recently discussed is for you to do the following exactly (where ${obj} is /usr/obj): /bin/rm -rf ${obj}/* 2> /dev/null || /bin/chflags -R 0 ${obj}/* && /bin/rm -rf ${obj}/* Then rebuild world/kernel again and do your installations. And though this isn't a cause of your problem, it's something you should be made aware of in the case you used csup or cvsup to move from HEAD to RELEASE: if all you did was change your supfile's tag line to match RELENG_9_0 (for example), but you didn't nuke /var/db/sup/src-all (or /usr/sup stuff if you use cvsup -- hope not) AND did not nuke /usr/src/*, then there could be src vs. sup database mismatches. This doesn't apply if you used svn natively, etc... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |