learning to buildworld
dthomas53 at gmail.com
Tue Apr 25 02:39:49 UTC 2006
On 4/24/06, Kevin Kinsey <kdk at daleco.biz> wrote:
> 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
> >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
> reboot (su preferred/wisest)
> But, frankly, the last "mergemaster" could be anywhere
> after the initial cvsup, I suppose. Kicks/pointers
> welcomed on that....
> >make installworld
> >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
> >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've done remote src upgrade a few times now and also have had no issues.
Although, I agree that you can probably only get away with this on low
> 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
> >my server is co-located, so its not exactly convenient to put it in
> >user mode, so if there is any reason to believe the whole processes can
> >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.
IP KVM is the way to go for something like this. This is assuming , though,
that you have a spare switchport and IP for it.
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 ;-) .
> Kevin Kinsey
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions