Solved

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

Posted on 2001-09-18
13
387 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
  • 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
 
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
Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

 

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

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

When you do backups in the Solaris Operating System, the file system must be inactive. Otherwise, the output may be inconsistent. A file system is inactive when it's unmounted or it's write-locked by the operating system. Although the fssnap utility…
Let's say you need to move the data of a file system from one partition to another. This generally involves dismounting the file system, backing it up to tapes, and restoring it to a new partition. You may also copy the file system from one place to…
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…

708 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now