Rebuilding the World Question

[Kevin D. Kinsey, DaleCo, S.P.]

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.