From owner-freebsd-questions@FreeBSD.ORG Fri Mar 16 13:42:02 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 6B0FA16A405 for ; Fri, 16 Mar 2007 13:42:02 +0000 (UTC) (envelope-from kdk@daleco.biz) Received: from ezekiel.daleco.biz (southernuniform.com [66.76.92.18]) by mx1.freebsd.org (Postfix) with ESMTP id 16CDF13C489 for ; Fri, 16 Mar 2007 13:42:01 +0000 (UTC) (envelope-from kdk@daleco.biz) Received: from archangel.daleco.biz ([69.27.149.254]) by ezekiel.daleco.biz (8.13.8/8.13.1) with ESMTP id l2GDfwrr083284; Fri, 16 Mar 2007 08:41:59 -0500 (CDT) (envelope-from kdk@daleco.biz) Message-ID: <45FA9EA0.1000300@daleco.biz> Date: Fri, 16 Mar 2007 08:41:52 -0500 From: Kevin Kinsey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2pre) Gecko/20070221 SeaMonkey/1.1 MIME-Version: 1.0 To: Drew Jenkins References: <743226.43661.qm@web62215.mail.re1.yahoo.com> In-Reply-To: <743226.43661.qm@web62215.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Corrupted OS 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: Fri, 16 Mar 2007 13:42:02 -0000 Drew Jenkins wrote: > How do I know the kernel has not become corrupted? Actually, as I think about it, I > should probably rebuild the kernel anyway to work with packet filters. > Here are my notes from the last time I updated: > > /usr/src/UPDATING and /usr/src/Makefile? > > I'm not sure what I mean by the above, but should I use the Makefile and not UPDATING? You meant to remind yourself to read those files. Esp. UPDATING. > synch your source to 6.2 > > How? And is this necessary since it's already at 6.2? The command below, "cvsup -g -L 2 supfile". Assuming, of course, that the supfile is valid. Is it necessary? Depends; if you're convinced that something is wrong with your current installation, then you might not need to, because you can rebuild exactly the system that you *should* have (for example, perhaps you fat-fingered a chmod or rm call?). OTOH, if you are attempting to get "up to date" on security fixes, etc., then you should read up on "the Cutting Edge" so that you understand the CVS tags, and use cvsup as shown below. Be *certain* you have the CVS tag you really want in the supfile before you press enter, though. Now, if you think that the system is corrupt because your source tree is corrupt, then you would also want to sync your source tree. Of course, why would it be corrupt? If a committer made an error, you'd probably see some discussion of it on this list of the stable@ list. > cvsup -g -L 2 supfile > cd /usr/src > make clean;make cleanworld I never do this, and am not really familiar with that target. Same as `rm -rf /usr/obj`, perhaps? I'll have to check, heh.... > make buildworld OK. Actually might need "mergemaster -p" before this on some occasions, but if you're not technically *updating* (i.e., you aren't getting new source code via cvsup), it shouldn't be an issue, but this is where it's supposed to go, not where you have it below. > cd /usr/src/sys/i386/conf/ > # back up any custom config there is > cp GENERIC BACKUP_CONFIG > cd /usr/src > make buildkernel KERNCONF=LOCAL # use this from now on! > make installkernel KERNCONF=LOCAL # use this from now on! > # Note: LOCAL is a copy of GENERIC in the same folder (/usr/src/sys/i386/conf/GENERIC) > # with changes for pf as follows: > # # Packet Filters > # device pf > # device pflog > # device pfsync > # options ALTQ > # options ALTQ_CBQ # Class Bases Queuing (CBQ) > # options ALTQ_RED # Random Early Detection (RED) > # options ALTQ_RIO # RED In/Out > # options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > # options ALTQ_PRIQ # Priority Queuing (PRIQ) OK, that's fine. This next stuff is a tad strange, any reason you can't just "shutdown -r now"? The point is to attempt to boot with the new kernel, and going to single-user at this point doesn't do that. > sh /etc/rc.shutdown # kills all your services > pkill sendmail > pkill syslogd > mergemaster -p As noted above, this ("mergemaster -p") is actually meant to be done "pre-buildworld" ... see mergemaster(8). Now, after the reboot (and technically, you're supposed to be in single-user now, but I've found on lower-traffic boxes it's generally not necessary for me to do that) you do this: > make installworld > mergemaster And you have a rebuilt system, kernel and userland. > reboot A reboot is not needed at this point, because you did it above. > /usr/local/bin/portmanager -u -f -l -y > make delete-old-libs This is about ports, so a different subject. ;-) > What happens if my internet connection dies when > I'm doing this? Will I still be able to SSH into my box? Err, my first thought was, what kind of a question is that? Without an internet connection you can't use SSH ;-) Thinking a tad more clearly, I suppose you mean, since the process of upgrading (buildworld, installworld, whatever) is attached to my terminal (which is an SSH session), what happens if I'm disconnected - will my upgrade continue? The answer is that it will not continue unless you've planned for that possibility. Are you familiar with job control, e.g.: $ make buildworld & HTH, Kevin Kinsey -- A real diplomat is one who can cut his neighbor's throat without having his neighbor notice it. -- Trygve Lie