From owner-freebsd-questions@FreeBSD.ORG Mon Jan 15 03:17:16 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF53716A601 for ; Mon, 15 Jan 2007 03:17:16 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2A45E13C459 for ; Mon, 15 Jan 2007 03:17:13 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup235.ach.sch.gr [81.186.70.235]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l0F3GPv6005498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jan 2007 05:16:40 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l0ELPglZ003795; Sun, 14 Jan 2007 23:26:28 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l0ELOvDR003789; Sun, 14 Jan 2007 23:24:57 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 14 Jan 2007 23:24:56 +0200 From: Giorgos Keramidas To: Bill Moran Message-ID: <20070114212456.GA3744@kobe.laptop> References: <73161.84816.qm@web51108.mail.yahoo.com> <20070114202517.GA3404@kobe.laptop> <20070114153515.ae528666.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070114153515.ae528666.wmoran@collaborativefusion.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.742, required 5, ALL_TRUSTED -1.80, AWL 0.46, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Dino Vliet , freebsd-questions@freebsd.org Subject: Re: advice on compiling a new kernel & upgrading to the latest sources X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 03:17:17 -0000 On 2007-01-14 15:35, Bill Moran wrote: > Giorgos Keramidas wrote: > [copious snippage] > > > 2. Cd /usr/src/sys/amd64/conf which contains the file MYKERNEL > > > > No it doesn't. CVSup will delete the files it doesn't know about, so > > you should *SAVE a copy* of your favorite kernel config file outside of > > the source tree and *copy* it into `/usr/src/sys/amd64/conf' after CVSup > > finishes updates the sources. > > Really? What have I been doing wrong? I've been keeping custom kernel > configs for years and cvsup has never deleted any of them. That's what the ``*default delete use-rel-suffix'' option does, AFAIK. The default supfile examples in `/usr/share/examples/cvsup' have this option enabled, and cvsup(1) says about it: delete The presence of this keyword gives cvsup permission to delete files. If it is missing, no files will be deleted. The presence of the delete keyword puts cvsup into so-called exact mode. In exact mode, CVSup does its best to make the client's files correspond to those on the server. This includes deleting individual deltas and symbolic tags from RCS files, as well as deleting entire files. In exact mode, CVSup verifies every edited file with a checksum, to ensure that the edits have produced a file identical to the master copy on the server. If the checksum test fails for a file, then CVSup falls back upon transferring the entire file. In general, CVSup deletes only files which are known to the server. Extra files present in the client's tree are left alone, even in exact mode. More precisely, CVSup is willing to delete two classes of files: o Files that were previously created or updated by CVSup itself. o Checked-out versions of files which are marked as dead on the server. If the option doesn't work this way, then I stand corrected. >>> 4.Copy everything under /etc to /root/etc >> >> Why? This isn't mentioned in `/usr/src/UPDATING' and it doesn't really >> help much if you manage to trash your /lib and /usr/lib trees. A better >> suggestion is to ``make sure you have good level 0 dumps'', as suggested >> by ``/usr/src/UPDATING''. > > While not mentioned in /usr/src/UPDATING, this is good practice in my > opinion. mergemaster can be a tedious task, and making a local backup > of /etc has allowed me to undo some careless keystrokes a number of times. > I don't disagree with the dump advice, but an additional copy of /etc > around doesn't hurt anything and occasionally makes fixing a mistake > much faster an easier. Heh, true :)