Date: Wed, 8 Oct 1997 08:39:34 -0600 From: John-David Childs <jdc@nterprise.net> To: freebsd-questions@freebsd.org Subject: Re: Best way to upgrade to 2.2.5-BETA? Message-ID: <19971008083934.35506@denver.net> In-Reply-To: <Pine.BSF.3.96.971007214548.5738C-100000@gdi.uoregon.edu>; from Doug White on Tue, Oct 07, 1997 at 09:46:40PM -0700 References: <199710072130.OAA21745@wiley.csusb.edu> <Pine.BSF.3.96.971007214548.5738C-100000@gdi.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday October 7, 1997, Doug White <dwhite@gdi.uoregon.edu> had this to say about "Re: Best way to upgrade to 2.2.5-BETA?": > On Tue, 7 Oct 1997, William Wong wrote: > > > Hello all, > > > > Can cvsup be used to upgrade an existing machine to 2.2.5-snap_date-BETA? > > If so, is there also a list of the different tags on the cvsup sites that > > I know I can cvsup to? > > > > If not, is getting the floppies from releng22.freebsd.org and then pointing > > the ftp site to releng22.freebsd.org for the latest betas the only way to go? > > It's probably the best way to go. Having done both, upgrading via boot.flp (binaries) is a lot easier ;) On my home machine, I installed 2.1.7 about two months ago and then built 2.2.2-RELEASE and 2.2-STABLE via the make world process (just to learn how the CVSUP process works, really, although my wife claims it was for masochistic reasons). I've since upgraded to 2.2.5-BETA (10-05) via make world. On Tuesday, I installed a "brand new" machine for one of my customers using 2.2.5-BETA 10-05 boot.flp. No major problems to speak of, and it was a lot faster ;) That said, some low-cashflow ISP's must upgrade via the make world process because the machine cannot go into single-user mode (it might be the mail/web server or something like that). I've done that too (the hard way...I didn't use cvsup) but I'd strongly advise against going from 2.1X to 2.2X that way unless you're prepared! The best thing to do is a make buildworld (I'm not sure if "buildworld" exists before 2.2-STABLE) to compile all the binaries into /usr/obj and THEN do a make installworld to install them. It'll keep your "downtime" to a minimum (downtime is that period between when you start installing new binaries on top of running binaries/kernel is messed up, ps/w/top don't work, etc. and when you install the new kernel and reboot). > The betas are regen'd daily, including > the latest bugfixes. Upgrade-by-make-world's take some careful merging to > keep from busting everything, particularly the kernel rebuild step. I've > never done this, it may be easier than it seems to me. :) > Once you've done it a few times, it becomes almost old hat. I cp LINT to <HOSTNAME> and start removing/changing items (although this isn't the recommended procedure...you're "supposed to" start with GENERIC and add the items from LINT you want...I find it easier to remove from LINT). Usually takes about 5-10 minutes to create the <HOSTNAME> kernel (I also diff the old <HOSTNAME> kernel against the new <HOSTNAME> kernel to catch things like network cards at strange IRQ's or flags to npx0). >From there, it's a matter of compiling, installing, rebooting, and crossing fingers...with the occaisional cuss-word thrown in for good measure ;) > Doug White | University of Oregon > Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant > http://gladstone.uoregon.edu/~dwhite | Computer Science Major > -- John-David Childs (JC612) Enterprise Internet Solutions System Administrator @denver.net/Internet-Coach/@ronan.net & Network Engineer 1031 S. Parker Rd. #I-8 Denver, CO 80231 As of this^H^H^H^H next week, passwords will be entered in Morse code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971008083934.35506>