From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 06:49:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E90CDF5C for ; Tue, 18 Nov 2014 06:49:32 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B32748A1 for ; Tue, 18 Nov 2014 06:49:32 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAI6oIL6005350; Mon, 17 Nov 2014 22:50:18 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Kevin Oberman In-Reply-To: References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <971085e211564c84a0460ca945eda837@ultimatedns.net>, From: "Chris H" Subject: Re: best overall upgrade from 8.x? Date: Mon, 17 Nov 2014 22:50:18 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <3930066eddaa3b17754f5f9cdfba5e6d@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 06:49:33 -0000 On Mon, 17 Nov 2014 22:13:11 -0800 Kevin Oberman wrote > This is a bit nit-picky, but... (in-line) > > NOTE personal experience indicates that regression issues introduced > > by pkg(8), makes >=8.3-* the minimum starting point. YMMV > > > > I have used the following for ~10yrs. w/o issue (comments added for > > *hopeful* clarity). > > > > The IMMEDIATELY following, is only relevant RE-building world/kernel: > > cd /usr/obj > > chflags -R noschg * > > rm -rf * > > > > > > cd /usr/src > > make buildworld > > > > NOTES: > > SINGLE CPU: make -j4 buildworld > > > > NOTE: > > MULTI CPU: make -j(6 through ??) buildworld > > > > # pre version 9 > > make kernel-toolchain > > > > make -DALWAYS_CHECK_MAKE buildkernel KERNCONF= > > > I would add -jN to this using the same value for 'N' as used for buildworld > > make -DALWAYS_CHECK_MAKE installkernel KERNCONF= > > > > reboot (in single user mode) > > > > fsck -p (optional, but a good idea) > > mount -u / > > > Redundant before the fact as the next command (mount -a -t ufs) does this, > too > > mount -a -t ufs > > swapon -a (most cases; optional) > > > > adjkerntz -i (not always necessary, but DO check current time/date, just in > > case) > > > In more fetail, if the hardware clock is UTC, this is not required. If > /etc/wall_cmos_clock exists, this is needed, but you really should do it > BEFORE mounting disks. UPDATING shows it right after the fsck. It avoids > any possibility of something being time-stamped in the future. > > > > > mergemaster -p > > > This is way, way to late. On at least one case, this would have lead to a > very awkward failure of installworld. The man page is explicit that it > should be run before buildworld. This is the only thing in this that is > really, really wrong and can lead to a recoverable, but very annoying > failure. 10yrs. and a few thousand installs, says otherwise... BUT, the more I know, the more I know I don't know. :) > > > > > > cp -Rp /etc /etc.old > > > Not really needed, but good for the "belt and braces" type. Yes. Just like recent dump(8)'s. ;) > > > > > cd /usr/src > > > > make installworld > > > > mergemaster -F > > or mergemaster -vF (my personal choice) > > or mergemaster -cvF > > > > make delete-old > > > This can be a bit painful as you are prompted for every file. I suggest > "make check-old" and then "rm -rf" any directories listed as ready for > deletion. direcctories are listed near the end, just before libs. > > > > > reboot > > > > HTH > > > > --Chris > > > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com --Chris