Solved

to jlevie: FreeBSD 4.x: Buildworld and Installworld on machines on diff specs?

Posted on 2001-09-18
13
401 Views
Last Modified: 2010-04-21
hi

I am upgrading my FreeBSD 4.1 box to 4.3 using the CVSUP, Buildworld and Installworld method. As recommended, the way to go is to CVSUP and compile (buildworld) on one fast machine, and then NFS share the /usr/obj and /usr/src to the production machines to "installworld".

My question is:
Does it matter if the "build" machine specs is different from the production "install" machine?
For example, say my build machine is a Celeron with IDE and my production machines are SMP Pentium with SCSI with different RAM size, will the "installworld" be OK?

Is the "build" process independent of the server it resides on ? I would think it should, as the specifics of the server is defined only in the kernel build and that buildworld creates only "generic" binaries ? Am I correct ?

Please advice, jlevie or any of the BSD experts out there?
Thanks !



0
Comment
Question by:thiamwah
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 4
  • 3
13 Comments
 

Accepted Solution

by:
_serega earned 100 total points
ID: 6493092
yes, you're correct. binaries are generic. But beware: some of them could use system calls that may be changed from different kernel versions, so you must sync your kernel land and user land. Generally, you can build kernel and world on any fast x86 machine, and then install kernel/world on the other x86 machine without any problems. Problems could happen if you install kernel without world, or install world without kernel.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 6493590
The system components and libs generated by a "make world" are processor and hardware independant. Hardware dependancies only occur for the kernel and it's drivers. If you use the GENERIC kernel config file, the resultant kernel will work on any CPU type and will have all of the common device drivers. And you can generate your own custom kernel config file that covers only the hardware on your systems. Sometimes that's more appropriate than building a custom kernel on each machine. Just be sure to include all of the devices that each of your systems needs in your config file.
0
 

Author Comment

by:thiamwah
ID: 6495407
guys,

ok, assumed that I have build kernel and world on any fast x86 machine, and I will now install world on the other x86 machines with different specs.

What I should do next is then to rebuild the kernel for each production machine to suit individual server hardware specs. Does this sound ok?

0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 40

Expert Comment

by:jlevie
ID: 6495527
If you've done a 'make buildworld' on you fast machine, then you can use that on the other machines. Simply export /usr/src & /usr/obj from the fast box and mount that on the other box. Then do a 'make installworld', followed by a 'mergemaster'.You can build the kernel on the fast machine, or on the slow box and install it in the normal manner. I usually do all my builds on a fast box and install the resultant kernel on the target system. In my case the systems are all similar enough to make it feasible to use a single kernel config file for all boxes except a firewall. The custom kernel config that I use includes support for all devices that I have on any of the boxes. And just to be explicit, some of my boxes are IDE, some are SCSI, and I also have two kinds of RAID controllers. I also have something like 4 different Ethernet adapters and three different CPU types. So the kernel config lists all of those devices.
0
 

Expert Comment

by:_serega
ID: 6495790
note that the current kernel version has extended modules's support.
you don't have to compile driver's code into kernel, kernel will autoprobe your box at boot time and load the appropriate module if needed.
recently modules where stored in /modules directory,
but I have them in /boot/kernel/ directory. and kernel itself strored there. (i'm using FreeBSD 5.0-CURRENT, maybe 4-STABLE still uses /kernel, but thing are definitely moving to the new scheme).
therefore make sure you have enough space in / partition,
'cause modules' code on my box eats about 13M.
if you have your root partition less then 50M, maybe it's time to extend it :-)
so, before you make custom kernel, think about the modules.
I'm using quite small kernel, but all the functionality including network drivers, autdio drivers added using modules stuff.

my advise also would be read handbook on www.freebsd.org 
about kernel build and NFS, documentation on freebsd site was greatly improved last time, and continue improving (that's good).

g'luck
0
 

Author Comment

by:thiamwah
ID: 6498637
I am thinking of upgrading it to FreeBSD 4.3 or 4.4.

"...note that the current kernel version has extended modules's support."

Does 4.3 and 4.4 fall under this new module support or the old one?


0
 

Expert Comment

by:_serega
ID: 6499171
on 4.3 i have had that.
i suggest you to upgrade to -STABLE, i.e. to 4.4
in supfile, make the default tag 'RELENG_4'
note that for ports and docs tag should always be '.',
i.e. -CURRENT.

take a look at such supfile example:

*default  host=cvsup3.freebsd.org
*default  base=/usr
*default  prefix=/usr
*default  release=cvs
*default  tag=RELENG_4
*default  delete compress use-rel-suffix

src-all
src-secure
doc-all         tag=.
ports-all   tag=.
0
 

Author Comment

by:thiamwah
ID: 6499386
hi serega,

sorry for not understanding "on 4.3 i have had that" :)
my question was:
Does 4.3 or 4.4 fall under this new module support or the old one?
Is it YES, it falls under the new module support or
NO, it does not have the new module support meaning the kernel is similar to that of 4.1 or 4.0..

Thanks
0
 

Expert Comment

by:_serega
ID: 6499443
what i was saying about 'new scheme' is just
the place where modules are kept.
i'm shure that 4.3 has them in /modules/,
and 5.0 in /boot/kernel/.
but i said that just to point where are they kept,
it absolutely doesn't matter, where exactly,
4.3 does have all autoprobing capabilities 5.0 has,
and the module format and ideology is absolutely the same.
so don't be confused by my words 'new scheme' and 'old scheme', they are not truly correct, they just reflect
the fact where they (the modules) are stored.
So, you can build basic kernel and use modules with no
problem on any 4.x box.
Just don't forget to archive you /etc/ and then run mergemaster, so it will update config files.

recently, back to 2.x kernels, FreeBSD had different
KLD (kernel loadable modules) mechanism, and it was changed
in 3.x. So that may be named as new scheme and old scheme.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 6500477
Yes the 4.x kernels all have loadable module support. But, what modules are built is still controlled by what you have in your kernel config file.
0
 

Author Comment

by:thiamwah
ID: 6504389
ah. I know what you mean. :)
I am currently using 4.1 which already has the loadable module support and it can be used by "kldload", "kldunload", and "kldstat",
So 4.3 is no different from 4.1 as it is still 4.x.
Only 5.0 has them in a different location.

Reason why I am so concerned is that because my / partition is kinda small (no thanks to the vendor that installed them) so I am cautious that any upgrading that might bloat up my kernel in / and give me heck of a problem.. :)


0
 

Author Comment

by:thiamwah
ID: 6504391
ah. I know what you mean. :)
I am currently using 4.1 which already has the loadable module support and it can be used by "kldload", "kldunload", and "kldstat",
So 4.3 is no different from 4.1 as it is still 4.x.
Only 5.0 has them in a different location.

Reason why I am so concerned is that because my / partition is kinda small (no thanks to the vendor that installed them) so I am cautious that any upgrading that might bloat up my kernel in / and give me heck of a problem.. :)


0
 

Author Comment

by:thiamwah
ID: 6504393
Both u and jlevie has given excellent guidance.. thanks!
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In tuning file systems on the Solaris Operating System, changing some parameters of a file system usually destroys the data on it. For instance, changing the cache segment block size in the volume of a T3 requires that you delete the existing volu…
Why Shell Scripting? Shell scripting is a powerful method of accessing UNIX systems and it is very flexible. Shell scripts are required when we want to execute a sequence of commands in Unix flavored operating systems. “Shell” is the command line i…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
In a previous video, we went over how to export a DynamoDB table into Amazon S3.  In this video, we show how to load the export from S3 into a DynamoDB table.

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question