learning to buildworld

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
> 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'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
volume boxes.

> 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.

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.

http://www.kvms.com/kvm-over-ip.asp

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

-David

_______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>