upgrading 4.0 to stable
Kenneth W Cochran
kwc at TheWorld.com
Thu Oct 2 19:06:54 PDT 2003
>Date: Thu, 02 Oct 2003 20:37:41 -0500
>From: "F. Even" <freebsdlists at elitists.org>
>To: <freebsd-stable at 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
More information about the freebsd-stable
mailing list