Drew Jenkins wrote:
How do I know the kernel has not become corrupted? Actually, as I think about
> 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,
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
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....
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.
# back up any custom config there is
cp GENERIC BACKUP_CONFIG
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
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:
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
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 &
A real diplomat is one who can cut his neighbor's throat without having
his neighbor notice it.
-- Trygve Lie
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"