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]
