Date: Thu, 2 Oct 2003 22:06:35 -0400 (EDT) From: Kenneth W Cochran <kwc@TheWorld.com> To: "F. Even" <freebsdlists@elitists.org> Cc: freebsd-stable@freebsd.org Subject: Re: upgrading 4.0 to stable Message-ID: <200310030206.WAA1003072@shell.TheWorld.com>
next in thread | raw e-mail | index | archive | help
>Date: Thu, 02 Oct 2003 20:37:41 -0500 >From: "F. Even" <freebsdlists@elitists.org> >To: <freebsd-stable@freebsd.org> >Subject: Re: upgrading 4.0 to stable Hello... >My problem being though is the box is about 60 mi. away and I have limited >access to it. I was hoping to be able to pull this off remotely.... While this is quote doable remotely (I've done it remotely myself), I'd *strongly* advise against it unless one has done it "at the console" several times. There's *no way* I'd be doing this remotely without some good experience doing it locally. >What I'm basically looking for is guidance on actually doing an upgrade. Just "IMO" but I wouldn't go more than one release at a time; I would probably go from one -RELEASE to the next, & finally, to -STABLE. Hmm, the more I think about it, the more I think I might instead follow the security branch of the various point-releases, then go to -STABLE... >So...when I CVSup, what tags should I do? Do there still exist tags for >RELENG_4_0, or is the next step straight to RELENG_4_3? Can I find the RELENG_4_0_RELEASE RELENG_4_1_RELEASE RELENG_4_2_RELEASE RELENG_4_3_RELEASE ... RELENG_4_8_RELEASE The tag without the "_RELEASE" (e.g. RELENG_4_8) is the "security" or "critical fix" branch. >"UPDATING" document that everyone keeps mentioning on the website anywhere >before I go grabbing source, etc.? I'd really like to find some reading >materials before I just dive into it...it just seems that the materials for >this topic are a little scarce on the site. > >Thanks, >Frank If you cvsup your source tree, *nothing* is affected outside /usr/src. If you totally hose /usr/src with a "bad" cvsup, all you need to do is correct the mistake & try again; no harm done. After a cvsup, /usr/src/UPDATING should have information relevant to what you just "got." Subsequently, "make buildworld" only "populates" /usr/obj, e.g. it takes /usr/src/* as "input" & makes /usr/obj/* as "output." Again, *nothing* in your running system is affected if something goes wrong here, so if something goes wrong, just fix it & rerun. There are (I think?) two tasks that affect your running system: make installworld - populates the "real" OS hierarchy from /usr/obj mergemaster - updates /etc as necessary, from various bits in /usr/src It stands to reason, then, that "make installworld" & mergemaster should be run only when you're quite comfortable with the prior steps, because there is not a very easy "recovery" from this "commit" should a problem occur. Sometime maybe I'd like to write up some kind of document that explains it from (I guess) "my" point of view... -kc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310030206.WAA1003072>