Date: Mon, 24 Apr 2006 13:50:23 -0500 From: Kevin Kinsey <kdk@daleco.biz> To: jhorne@dfwlp.com Cc: freebsd-questions@freebsd.org Subject: Re: learning to buildworld Message-ID: <444D1DEF.1020001@daleco.biz> In-Reply-To: <53858.208.11.134.3.1145894538.squirrel@mail.dfwlp.com> References: <53858.208.11.134.3.1145894538.squirrel@mail.dfwlp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Horne wrote:
>i have begun spending a good deal of time researching and practicing the
>buildworld process on my dev boxes. i want to make sure i have the entire
>process down pat, before i attempt it on my production server.
>
>
So, Mr. Murphy has never visited? "down pat" is probably
an oxymoron..... ;-)
>the handbook states that i should:
>
>make buildworld
>make buildkernel
>make installkernel
>
>and then reboot to single usermode. the installworld comes while in
>single user mode, and my production server would see quite a bit of
>downtime over this. handbook says to, in sigle user mode:
>
>mergemaster -p
>
>
/etc/ is not updated by "buildworld" nor "buildkernel",
hence the need for mergemaster (to get the new files
into /etc/ if anything has changed).
Note, from mergemaster(8), that the "-p" option is
"pre buildworld"; so, to place this at this juncture is
assuming that nothing in /etc/ has changed to the point
of destroying the "build world" procedure. If it has, then
you should run "mergemaster -p" before *anything* else....
This wasn't the case with the last rebuild I did (Saturday).
The newly-built world couldn't be installed without the
"audit" group, so "mergemaster -p" was necessary before
"installworld", but "buildworld" had been fine without it.
It all depends. Which brings up another point ... the
*real* first step is, "read /usr/src/UPDATING".
Here's the brass tacks:
*You may have to "mergemaster -p" before buildworld.
*You *must* buildworld before buildkernel if you want
the new kernel to match the new world.
*You must build a world and a kernel before you install
either. ;-)
*You probably don't want to install the new world before
you install the new kernel, 'cause currently running
programs could be affected, or might cause problems
with the current kernel. But, I guess you *could*....
*You have to reboot to run a new kernel, so you must
install the kernel prior to a reboot. When you reboot,
your kernel will be using an old userland until the new
world is installed. Probably won't cause many issues,
but it could.
*It's possible that installing a new userland/world while
running could interfere with some processes/users/whatnot.
*It's possible that programs running after the world is reinstalled
need something in the new /etc/.
From this, one might extract this sequence:
cvsup your source
read /usr/src/UPDATING, take notes
mergemaster -p
buildworld
buildkernel
installkernel
reboot (su preferred/wisest)
installworld
mergemaster
But, frankly, the last "mergemaster" could be anywhere
after the initial cvsup, I suppose. Kicks/pointers
welcomed on that....
>make installworld
>mergemaster
>reboot
>
>ive seen several articles on the net, and of course, no one agrees on the
>exact steps to take to update your system. my question is, is it safe to
>'mergemaster' and 'make installworld' while still up and running? or do i
>just need to bite the downtime-bullet, and put it in single user?
>
>
As you have probably noted, various "authorities" will give you
different answers. 'Nix is "tools, not policy". There are a few
ways to skin the cat....
It is possible to "installworld" after a remote reboot on a
low-trafficked machine without issues --- I do it all the time
(in fact, the entire process, with the exception of the reboot,
is scripted). But, I've been visited by Mr. Murphy once
or twice in the almost 5 years I've done this. Fortunately, my
"co-location" is only 20 minutes away, and I've a key... at
least for one of my production systems (I rebuild the other
during office hours ;-)
I note from previous responses that for some people, such a
strategy is not acceptable at all. YMMV; mine does.
You might ask if anyone uses a "limited reboot" strategy. You
could turn your daemons off in /rc.conf prior to the reboot, and
set your firewall to only allow you in; then perform the last steps
and re-enable the daemons/firewall, etc.
Of course, the real problems start if the kernel panics on reboot,
and you're sitting in your chair 300 miles away on a Sunday
afternoon, wonder why "ping myhost" still isn't working after 240
seconds....
>my server is co-located, so its not exactly convenient to put it in single
>user mode, so if there is any reason to believe the whole processes can be
>completed safely without single-user mode, then i will probably try it.
>
>
It's possible to enter single-user remotely via the use of a second
box and a serial console arrangement, but it's not something I've
needed to investigate.
I'd recommend practicing on a "scratch" box, for starters. Also,
it'd be a real Good Thing(tm) if a tech at the colo knows his BSD
stuff, and his time is included in your contract ;-) .
HTH,
Kevin Kinsey
--
He played the king as if afraid someone else would play the ace.
-- John Mason Brown, drama critic
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444D1DEF.1020001>