From owner-freebsd-stable Fri Mar 24 12:49:42 2000 Delivered-To: freebsd-stable@freebsd.org Received: from europe.std.com (europe.std.com [199.172.62.20]) by hub.freebsd.org (Postfix) with ESMTP id B796E37B66A for ; Fri, 24 Mar 2000 12:49:02 -0800 (PST) (envelope-from kwc@world.std.com) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id PAA27456; Fri, 24 Mar 2000 15:48:57 -0500 (EST) Received: (from kwc@localhost) by world.std.com (8.9.3/8.9.3) id PAA00854; Fri, 24 Mar 2000 15:44:25 -0500 (EST) Date: Fri, 24 Mar 2000 15:44:25 -0500 (EST) From: Kenneth W Cochran Message-Id: <200003242044.PAA00854@world.std.com> To: Matt Loschert Subject: Re: Questions source-upgrading 3.4-s to 4.0-s Cc: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From loschert@servint.com Fri Mar 24 14:02:06 2000 >Date: Fri, 24 Mar 2000 13:55:23 -0500 (EST) >Subject: Re: Questions source-upgrading 3.4-s to 4.0-s > >On Fri, 24 Mar 2000, Kenneth W Cochran wrote: >> It appears that my new 4.0 system (& the new C compiler) will be >> built using the 3.4-stable tools; is this ok? I'm guessing that >> the "last step(s)" of this process is to re-gen (cvsup/make >> [build, install]world...), just as I've always done with 3.x. > >Before building your new 4.0 userland, the buildworld process >builds the 4.0 compiler (gcc-2.95.2) (along with other build >tools), and then uses that to compile everything (including >recompiling the compiler). So buildworld runs in its "own complete isolated" environment? IOW, buildworld uses its "own" tools, etc., & doesn't need ie. /bin, /usr/bin ... ?? (Except for a few basic things, like the compiler (with which to "bootstrap" itself?"... :) >> It also appears that I cannot run a 3.x kernel with a 4.x >> userland (or is that a 4.x kernel with a 3.x userland?), so I >> have to get my userland built but not installed, then build, >> install & boot my new 4.x kernel, & *then* do my userland >> install (installworld). Is this correct? > >Yes, that's correct. Makes sense... So noted... >> [***] >> - I'm using the 4.x-stable-supfile from the examples in >> 3.4-s. What are the best things to un-comment in that >> config? (to handle crypto things, for example...) > >Make sure you specify to make 4.0-STABLE your default: >*default tag=RELENG_4 That's already in the example 4.x supfile & I've been running this cvsup in "test" mode just to See What It Does... >Use the following to get all 4.0-STABLE source including crypto: >src-all Of course... :) >cvs-crypto UPDATING says "Crypto & secure are now required." That, as I understand would be src-crypto and src-secure. How would these differ from cvs-crypto? Ie. would it be "better" to use those 2 "tags" or to use the one cvs-crypto? I suppose what I may be asking is "how do I make my new system look most like the distributed CDs?" >If you want the latest ports collection and documentation, specify: >ports-all tag=. >doc-all tag=. I do that with a separate cvsup file/job... >> - What's the difference between what I'd get as North >> American vs not? (& what's the best way to "identify" >> myself as North American? (What is going to ship on >> the CDs?) > >Offhand, I am not sure what all of the differences are. To >identify yourself as from USA, specify USA_RESIDENT="YES" in >/etc/make.conf. Then, point cvsup to a USA cvsup server in your Aha! (Thanks... :) >supfile using something like: >*default host=cvsup.FreeBSD.org I use one "closer..." >> cd /usr/src >> [**] >> make buildworld >> - Ok... This will take my new 4.x /usr/src & make a nice >> new /usr/obj... >Yes. Okay/check... >> - MAKE_KERBEROS4 is already commented-out in my >> /etc/make.conf, so I should be ok here? >Yes. Okay/check... >> cd sbin/mknod >> make install >> - What's this about? Is this /usr/sbin/mknod or is it >> /usr/src/sbin/mknod? >> How does this differ from cd /dev; sh MAKEDEV? > >cd /usr/src/sbin/mknod && make install Along the lines of "dotting all the "i"s & "crossong all the "t"s", I believe it would be a Good Idea to make this more explicit in the instructions... :) >> cd sys/modules >> make install >> - Same here... What's this about? I'm thinking this (& >> previous are relative to (my new 4.x) /usr/src, ie. >> /usr/src/sys/modules, or perhaps /sys/modules... > >cd /usr/src/sys/modules && make install Here, too... :) >> [*] >> - My system is all-scsi (/dev/da*). Do I need to do >> anything special? > >Not if you have da* sepecified for you SCSI hard drives. If you >have sd* devices, these need to be updated to da*. My devices are indeed da*; it was fresh-installed from the 3.4-RELEASE CDs, so it appears that I can skip this step? My /etc/fstab should also be ok? >> - "As above?" Again, how does this differ from cd /dev; >> sh MAKEDEV? > >You need the new MAKEDEV script for 4.0 from /usr/src/etc. As >far as I know, once you copy the new script into /dev, 'sh >MAKEDEV all' should work fine. I could be wrong for certain >configurations. Hmmm... Perhaps this needs more clarification? >> reboot >> >> - If I understand correctly, hit the spacebar & type -s? > >You probably should boot into single-user, but I have done it >successfully after booting multi-user. I'm one of those "safety freaks" who always goes single-user for installworld... :) >> cd /usr/src >> make -DNOINFO installworld >> - Why -DNOINFO? > >The new texinfo IIRC relies on new features that are not part of >the build chain. It tries to install itself using the existing >install-info program that does not have the features and bombs out. > >-DNOINFO skips installing the info files, thus not needing the >new install-info. Ah! Thanks! >> make installworld >> - & my guess is that this "corrects" the -DNOINFO >> installworld I just did? > >This essentially just installs the info files that were left out >during the previous step. Makes sense now; thanks! >> reboot >> >> - At this time I'm guessing it would be a Very Good Idea >> to do at least a [build, install]world, so as to get >> everything built with the new C compiler & tools, etc... > >Not necessary. As mentioned above, the new compiler was used to >do last buildworld. Interesting... :) >> To build a kernel >> ----------------- >> cd /usr/src >> # If you have not already done so, please buildworld here >> make buildkernel KERNEL= >> make installkernel KERNEL= >> # Verify that the new kernel works, it will be installed as >> # /YOUR_KERNEL_HERE >> chflags noschg /kernel >> mv /kernel /kernel.old >> mv /YOUR_KERNEL_HERE /kernel >> chflags schg /kernel >> >> - Is this still the same as: >> cd /sys/i386/conf >> >> config >> cd /sys/compile/GENERIC >> make depend >> make >> make install > >The kernel build process that you are familiar with relies on >already installed tools. Since the new 4.0 tools are not >installed at this point, you can't use them to build your 4.0 >kernel. The buildkernel and installkernel targets use tools >built (but not installed) during the buildworld phase to ensure >that everything is in sync. Aha! :) >> - Other than that, I'm guessing that I need to build & >> install the GENERIC kernel? > >For the upgrade, yes, install GENERIC. Once you have rebooted >after the upgrade, it is much safer to rebuild your custom kernel. So, substitute GENERIC for "YOUR_KERNEL_HERE?" >Hope this helps. Very much! Many thanks! I think it would be a Very Good Idea to get "appropriate portions" of this information into the UPDATING instructions; it might help slow down the upgrading-deluge "here" on -stable... :) -kc >- Matt >-- >Matt Loschert loschert@servint.com >Software Engineer voice (703) 847-1381 >ServInt Internet Services fax (703) 847-1383 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message