I'm still kind of hung up looking for some definitive answers on this issue. Perhaps you guys can help me out? Frank Date: Mon, 29 Sep 2003 17:55:33 -0500 (CDT) From: "F. Even" <freebsdlists@elitists.org> Subject: re: upgrading 4.0 to stable To: freebsd-questions@freebsd.org Message-ID: <20030929225533.81D352FE@elitists.org> Content-Type: text/plain; charset=iso-8859-1>------------------------------------------------------------- >Adam McLaurin adam.mclaurin at gmx.net >Sun Sep 28 20:20:47 PDT 2003 > >On Sun, 28 Sep 2003 21:57:04 -0500 (CDT) >"F. Even" <freebsdlists at elitists.org> wrote: > >> I would like to upgrade a 4.0 machine to STABLE, or at least to the >> RELENG security level. How difficult will this be? Is >there anything >> >> special that I need to be concerned about, so I don't get bit? This >> is kind of an important box....and I don't want it to take a >nose-dive >> >> after I reboot it remotely. > >The most common advice is to upgrade incrementally. Upgrading >directly from 4.0 to 4.8 is likely to encounter problems.OK.>I personally would recommend 4.0 to 4.3, then 4.3 to 4.6.2, >then 4.6.2 to 4.8. Check the handbook for the appropriate CVS tags.I was planning on using CVSup. Can I use the section on CVS tags for this? This is the page I found, correct?: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html>In any case, it is *very* important that you read >/usr/src/UPDATING each time you update your source. This will >inform you of any special steps you need to take before >upgrading to that respective version. > >If you're especially paranoid and have plenty of time, you >could even do the upgraded in more increments than I >recommended. Just be sure to read the UPDATING file each time.Now what is really recommended? Assuming I can use the CVS tags for CVSup, what should I do? Can I use the "release" tags? Like RELENG_4_0_0_RELEASE. Should I? Should I bother going to a "STABLE" version and just update my "RELEASE?" ...or, should I CVSup my machine to every "RELEASE" branch until I get to the current one. ..or should I go directly to the RELENG_4_3 and then upgrade every level of that. I don't really see much in the way of guidance in the handbook of what I should do to bring this box to some state of being "current." Hence...my pleading for assistance here. ;-) Thanks for any help. Frank ------ End of Forwarded Message
On Thu, Oct 02, 2003 at 04:40:03PM -0500, F. Even wrote:> I'm still kind of hung up looking for some definitive answers on this issue. > Perhaps you guys can help me out? >This is the supported upgrade path. But you should follow the "To update from 4.0-RELEASE or later to the most current 4.x-STABLE" instructions in src/UPDATING very closely, the most important thing is installing and rebooting with the new kernel before running installworld. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20031003/94029b76/attachment.bin
F. Even wrote:>I'm still kind of hung up looking for some definitive answers on this issue. >Perhaps you guys can help me out? > >Frank > > >>I personally would recommend 4.0 to 4.3, then 4.3 to 4.6.2, >>then 4.6.2 to 4.8. Check the handbook for the appropriate CVS tags. >> >>Hi, Following the above advice I would use the following cvsup file: *default host=*Insert CVSup mirror here* *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_4_3 *default delete use-rel-suffix *default compress src-all This will fetch the source for 4.3-RELEASE + security fixes, (for the release I think the tag is RELENG_4_3_0). Do the normal make buildworld & kernel dance as documented in UPDATING and the handbook. Then repeat the whole process with RELENG_4_6 as the tag and then again with RELENG_4_8 (and RELENG_4_9 if you want 4.9 release). This will take some time especially if your machine is slow at building. It might be worth verifying each step works by running with it for a day or two before going onto the next step. Also be sure to have good backups. Having said that I do builds all the time and have never had a significant problem. Cameron
On Thu, 2 Oct 2003, F. Even wrote:> I'm still kind of hung up looking for some definitive answers on this issue. > Perhaps you guys can help me out?The definitive answer is, back up your data, and do a clean install of the version you want to run. I'd suggest waiting for the upcoming 4.9-Release. Any other method has way too many dangers and complexities. HTH, Doug -- This .signature sanitized for your protection
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....
What I'm basically looking for is guidance on actually doing an upgrade.
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
"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
--------
upgrading 4.0 to stable
Doug Barton DougB at FreeBSD.org
Thu Oct 2 15:13:07 PDT 2003
* Previous message: upgrading 4.0 to stable
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 2 Oct 2003, F. Even wrote:
> I'm still kind of hung up looking for some definitive answers on this
issue.
> Perhaps you guys can help me out?
The definitive answer is, back up your data, and do a clean install of
the version you want to run. I'd suggest waiting for the upcoming
4.9-Release. Any other method has way too many dangers and complexities.
HTH,
Doug
>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 stableHello...>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 theRELENG_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, >FrankIf 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
On Thu, 2 Oct 2003, F. Even wrote:> I'm still kind of hung up looking for some definitive answers on this issue. > Perhaps you guys can help me out?Just get the CD and do a splat-over upgrade. Source building will take too long :) And IMHO I'd stick to the _RELEASE tags if you're paranoid. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
On Oct 2, 2003, 16:40 (-0500) F. Even <freebsdlists@elitists.org> wrote:> I'm still kind of hung up looking for some definitive answers on this issue. > Perhaps you guys can help me out?I do not think there is any definite answer, but I have tried and succeeded to update a remote machine from 4.3 to 4.8 without consol access. I know (and knew) that there are risks, I thought it was worth trying. Before updating the remote machine, I tried on a few machines that I could access the console on. * You have to have a stable connection to the remote machine. Do not use the recepie below for a machine that your life depends on... * I fetched sourch of RELENG_4_8 with cvsup. I would not recommend fetching STABLE in this case. * I updated by building world and kernel following the steps in /usr/src/Makefile: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `mergemaster' # 9. `reboot' * Make sure that the kernel is as simpel as possible. Do not add anythin outside GENERIC that you have not tested, and do not remove anything your are sure you don't need. * If your kernel contains IP-Firewall, do add IPFIREWALL_DEFAULT_TO_ACCEPT or you might not be able to log in when you have a new kernel but an old userland. * It is a good idea to disable services like httpd and named before you reboot after upting kernel, but do not remove loading of libraries or you might not be able to "su" (which happened to me on one trial machine). * It could be good to open ssh for root login during update. And if it is possible to install a statically build sshd it might also be a good idea. * And lock anyone else out of the machine during update. * Directly after installing world, restart sshd and test from another shell. Well, do not blame me if your loose contact with the computer, or if it cannot boot. :-) Mats ---------------------------------------------------------------------- Mats Dufberg <dufberg@nic-se.se> ----------------------------------------------------------------------
I have done one from 4.5 to stable the easiet way is to use screen if you dont have a stable connection in this order (make sure nothing else is running ie shutdown services except sshd ) and append the KERNCONF=blah make buildworld make buildkernel make installworld make installkernel mergemaster -p reboot cross your fingers and hope:) Ive had it fail only once