• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 414
  • Last Modified:

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

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
thiamwah
Asked:
thiamwah
  • 6
  • 4
  • 3
1 Solution
 
_seregaCommented:
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
 
jlevieCommented:
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
 
thiamwahAuthor Commented:
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
Independent Software Vendors: 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!

 
jlevieCommented:
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
 
_seregaCommented:
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
 
thiamwahAuthor Commented:
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
 
_seregaCommented:
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
 
thiamwahAuthor Commented:
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
 
_seregaCommented:
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
 
jlevieCommented:
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
 
thiamwahAuthor Commented:
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
 
thiamwahAuthor Commented:
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
 
thiamwahAuthor Commented:
Both u and jlevie has given excellent guidance.. thanks!
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now