Date: Fri, 24 Mar 2000 15:44:25 -0500 (EST) From: Kenneth W Cochran <kwc@world.std.com> To: Matt Loschert <loschert@servint.com> Cc: freebsd-stable@freebsd.org Subject: Re: Questions source-upgrading 3.4-s to 4.0-s Message-ID: <200003242044.PAA00854@world.std.com>
next in thread | raw e-mail | index | archive | help
>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... >> <see notes below (updating to 4.0-stable sources> [***] >> - 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 >> <see notes below> [**] >> 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... :) >> <follow rebuild disk /dev entries above> [*] >> - 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... <scratching chin...> Perhaps this needs more clarification? >> reboot >> <in single user> >> - If I understand correctly, hit the spacebar & type -s<cr>? > >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 >> <multi-user> >> - 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=<YOUR_KERNEL_HERE> >> make installkernel KERNEL=<YOUR_KERNEL_HERE> >> # 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 things...> >> config <whatever, probably GENERIC in this case...> >> 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! <light coming on...> :) >> - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003242044.PAA00854>