Bart Silverstrim wrote:

Here's a definite question from a first timer, but there are so many variations out there that I thought I'd bounce this off the list and see what people thought (if I was doing this "correctly")


Will do. While you're at it, for your second time, wrap your email lines at about 80 characters for those who are reading on text consoles (there are a few....)

I have a 4.9-RELEASE installation. It was recently pointed out to me that to get all the bug fixes and security fixes, I need to cvsup with "RELENG_4_9", not "RELENG_4_9_0_RELEASE". So...here's the src-supfile I am using:
*******
*default host=cvsup7.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
*default tag=RELENG_4_9


src-all
doc-all
*****
(does the tag=. matter here?)


I think so.  My "stable-supfile",
which I believe is a direct copy of
the one in /usr/share/examples/cvsup,
contains this:

*default release=cvs tag=RELENG_4_9

I run it with
cvsup -g -L 2 src-supfile
glance over /etc/make.conf


Some would use a stronger term
than 'glance' :-)

cd /usr/src
make buildworld
make buildkernel
make installkernel
reboot into single user mode with "boot -s"
mergemaster -p
make installworld
mergemaster
reboot into normal multiuser mode


Classic, and correct, to the best of my recollection, and experience.

One source I found said that they allow mergemaster to pretty much overwrite files unless it is asking about
/etc/passwd
/etc/hosts
/etc/groups
/etc/master.passwd



Well, anything that you've changed.... How about /etc/mail/aliases? How about /etc/rc.conf, or /etc/hosts.allow? It really depends on what you've been adjusting.

This is an update from 4.9 release to the (hopefully) security updated version, and the system is running a generic kernel and is a pretty stock install (some ports are in place, but port updates are done separately, as I understand it)


Portupgrade is generally a wonderful tool.


Are there any steps or pieces of advice I'm missing here? Advice/explanations/etc. are all appreciated. Thanks!


You can have cron do some of these steps.

If you're doing this remotely, you can pipe the
output away from the terminal to a logfile, saving
bandwidth, perhaps, and leaving a record should
something go wrong ... perhaps like:

make buildworld > /home/me/buildworld.log &

You could also redirect stderr, which would
probably be advisable.  There are a couple
of tools for this purpose too; IIRC, one of them
is "script" ... but I've not yet tried it.

Also, during remote upgrades, if the box is
not terribly active, it is possible, though risky
perhaps, to simply reboot into multi user with
the new kernel.  The reason for booting single
user is probably twofold:  to make sure the
new kernel works, and to avoid any kind of
problem that might arise from other processes
utilizing parts of the world while it is being
installed.

I'm not recommending it; but I have done it.
You just sweat a little harder, and definitely
curse yourself in the very rare instance of
breakage, which I've never encountered with
4.X AFAIK....

Kevin Kinsey
DaleCo, S.P.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to