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 

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
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 
# 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

And you have a rebuilt system, kernel and userland.


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 &


Kevin Kinsey
A real diplomat is one who can cut his neighbor's throat without having
his neighbor notice it.
                -- Trygve Lie
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to