The make-world script
Do you remember that makefile I had for my upgrade from FreeBSD 4.0-Release to FreeBSD 4.0-Stable. Well, gill wrote in with an improvement. It doesn’t make things any faster. But it does make the script easier to configure. I’ve updated the old script with his changes and the script is available here.
WARNING: Do not use copy/paste to get the makefile. Makefiles contains tabs. The copy/paste process will convert the tabs to spaces. You don’t want that. You need the tabs. Instead, use fetch to get the file (e.g fetch <filename>).
Also remember that this script puts logs into /usr/tmp. You may wish
to delete those logs after you are finished. They can get quite big. You can
modify the location by modifying a variable in the script.
Some people say there is no need for this script. Well, that’s true. But I like it because it keeps the logs for you in case something goes wrong. “But you can do those logs yourself!”. Well, yes, but if I use the script, it is done for me. If you don’t like the idea, you won’t be using it.
The assumptions
- You are familiar with Using make world.
- perform all these steps as root
- the make script resides in
~/make - the script resides within a file called
Makefile. - You have installed cvsup. See getting cvsup installed for details.
- you modify the script variables accordingly (at a minimum, set
MYKERNEL). - read that URL I mentioned. getting cvsup installed
- go read that URL. now. getting cvsup installed
Using the script
On 26 August, 2001, I changed the script slightly. It now requires changes to /etc/make.conf (you should create that file if it doesn’t already exist). Ensure the following entries exist in that file:
NOTE: I have not been able to get the above to work. I have had to resort to upgrading my source by issuing the cvsup command directly. Here are the steps I go through to build my world.SUP_UPDATE= yes SUPFLAGS= -g -z -L 2 SUPHOST= xeon SUPFILE= /usr/share/examples/cvsup/stable-supfile
Before you use the script,
remember to change the variable in the script to suit your requirements. You must
set MYKERNEL to the appropriate value (see the following NOTE). And you may wish to
change the default location for the logs. By default, they go to /usr/tmp.
If you don’t change that value, make sure /usr/tmp exists.
NOTE: If you have not previously downloaded the kernel source and created a kernel configuration file, then you must create this file after step 2 and before step 5. Please refer to the Configuring the FreeBSD Kernel section in the FreeBSD handbook. Pay special attention to the section on Building and Installing a Custom Kernel.
If you have previously done a build world, you should remember to do a make clean first. It clears out /usr/obj as well as deleting your old log files.
This section outlines the steps which are detailed below. This intended to be a
quick reference for those who are familiar with the steps and just need a quick reminder
of what to do. Again, this assumes you have installed the makefile in ~/make
when you were su’d to root.
Remember to create your kernel configuration file first and set the name of this file
within the Makefile (see MYKERNEL).
These instructions are for the Makefile provided at the top of this page.
suto rootcd ~/makemake update– updates your source, if it already exists!make build– does a build world.make kernelbuildmake kernelinstall- reboot*
mergemaster -pmake install– installs the results of the above buildsmake merge– merges the configuration file changes- reboot
*WARNING! WARNING!:/usr/src/UPDATING recommends a reboot here just to make sure the
kernel you just built is operational. If it is not you can still reboot to
kernel.old and still have your world and kernel in sync. For what it’s worth, I
don’t usually do this reboot. And once, when I was upgrading to 4.4, I actually broke my
box big time. If you do this reboot, note that ipf will possibly break because
you are (for example) using a 4.4 kernel with a 4.3 world. If you also use
IPFILTER_DEFAULT_BLOCK, then you’ll be locked out of the box. Your only way back in
will be via the console. BE WARNED!
If you encounter the following error:
# make update
cd /usr/src; make update 2>&1 | tee /usr/tmp/update.`date "+%Y.%m.%d.%H.%M.%S"`.log;
make: don't know how to make update. Stop
cvsup -h xeon /usr/share/examples/cvsup/stable-supfile
where xeon is the name of your favorite cvsup server. I know I have to issue
the above command when I first cvsup a box (e.g. I just installed 4.4-RELEASE and I want to upgrade the
system to 4.4-STABLE.
It could also be that upgrading from an older version of FreeBSD which does not support
make update. For example, I know 4.2-Release does not have this feature.
In which case, you should run cvsup manually to upgrade your sources. There is a small example
of how do this within Installing cvsup.
making a kernel when not making world
You can also use this script to build a kernel when you aren’t building world. You can usemake kerneloldstyle. If you try to make a kernel, and get an
error like this:
/tmp/ccb33757.s:2468: Error: Subtraction of two symbols in different
sections "IdlePTD" {.data section} - "KERNBASE" {*UND* section} at
file address 1596.
*** Error code 1
then try make kerneloldstyle instead.
Using mergemaster
mergemaster is a most awesome piece of code. It simplifies the process of merging system file changes to a level which is quite simple. Without it, I would not like to do a build world.mergemaster looks at the files in existing system and compares them to the new files, which are temporarily located in another directory. For each new file which differs from the existing file, it prompts you for instructions. The options are generally:
- merge (take bits from each file)
- delete (ignore the new file and keep the existing file)
- insert (the new file, overwriting the existing file)
During the merge, you are presented with left and right images of the before and after images. You may have to scroll back up to figure out which is the new file and which is the old file. Quite often, the first line mergemaster shows you contains a version number. That will differentiate the new file from the old file. It takes a while to get used to it, but after a while you will get the hang of it.
HI,
for those of you interested in fixing the make update problem, I did find a fix for it, I decided to do some testing and got it running, so I thought I post my setup here and advise those interested.
the only changed to make are in the /etc/make.conf.
depending on how you have your supfiles setup you will not have to specify the SUPHOST. I found that once removed from make.conf, the make update command worked without problems.
make update uses the cvs servers you have specified in your supfile.
below is listed what i have in my make.conf for cvsup section.
Notice as well I have included the configuration entries which update my ports and docs as well as stable.
SUP_UPDATE= yes
SUPFILE=/root/make/stable-supfile
PORTSSUPFILE=/root/make/ports-supfile
DOCSUPFILE=/root/make/doc-supfile
SUPFLAGS= -g -z -L 2
I hope this helps others out there, as I am still pretty new to freebsd, and thought I would share what I found.
Cheers
David
What did you have for SUPHOST= in /etc/make.conf?
What entry do you have for *default host= in /root/make/stable-supfile?
Dan,
I removed the entry in /etc/make.conf and just used the default host in each of the sup files.
the entry for *default host= in /root/make/stable-supfile is cvsup.au.freebsd.org
I have this specified in all the supfiles I have mentioned in my last post.
Regards,
David
I don’t yet understand why putting this in /etc/make.conf did not work:
SUPHOST= cvsup.au.freebsd.org
That should be a tab, not a space there….
Dan,
1) I haven’t used tabs, I have used spaces in /etc/make.conf
2) I did not specify SUPHOST in /etc/make.conf, I am using the the default host entry that is specified in each of the cvsup config files.I have not yet tested the SUPHOST in etc/make.conf but I will certainly do that shortly and let you know.
do you get a better idea of what I’m saying now?
sorry if its confusing I think I need to stop composing emails at ridiculous hours of the morning, sometimes I do no make sense 🙂
here is the contents of etc/make.conf in full.
CFLAGS= -O -pipe
NOPROFILE=true
USA_RESIDENT=NO
SUP_UPDATE= yes
SUPFILE=/root/make/stable-supfile
PORTSSUPFILE=/root/make/ports-supfile
DOCSUPFILE=/root/make/doc-supfile
SUPFLAGS= -g -z -L 2
Regards,
David
David Heaps wrote:
> do you get a better idea of what I’m saying now?
> sorry if its confusing I think I need to stop composing
> emails at ridiculous hours of the morning, sometimes I do no
> make sense 🙂
Your original post led me to believe there was a problem which you solved:
"for those of you interested in fixing the make update problem, I did find a fix for it, I decided to do some testing and got it running, so I thought I post my setup here and advise those interested."
What is this "make update" problem?
Dan,
I just added the SUPHOST(and specified a different cvsup server to update from) in the make.conf. I tested this and it work fine, it overode the default host server I had specified in each of the cvsup files.
I did another test, i changed the spaces to tabs, and vice versa it didnt seem to matter either way whether you used tabs or spaces.
SUP_UPDATE= yes
SUPHOST= cvsup.freebsd.org
SUPFILE= /root/make/stable-supfile
PORTSSUPFILE= /root/make/ports-supfile
DOCSUPFILE= /root/make/doc-supfile
SUPFLAGS= -g -z -L 2
So specified above is what finally works for me.
Regards,
David
Dan,
Hmm I should have been a bit more specific (apologies).
In your original article under the "The make-world script" dated 30-July-2000, I am referring to the the "NOTE" you added (See Below), this is the bit I was trying to help fix.
— Paste from Article
"USING THE SCRIPT"
On 26 August, 2001, I changed the script slightly. It now requires changes to /etc/make.conf (you should create that file if it doesn’t already exist). Ensure the following entries exist in that file:
SUP_UPDATE= yes
SUPFLAGS= -g -z -L 2
SUPHOST= xeon
SUPFILE= /usr/share/examples/cvsup/stable-supfile
NOTE: I have not been able to get the above to work. I have had to resort to upgrading my source by issuing the cvsup command directly.
— Finish Paste
Regards,
David
Thanks!
I’m not sure about that reported problem. I suspect it’s when I have a brand new box without source. I’ll have to investigate further the next time I set up a box.
cheers.
I tried making a new kernel the "Traditional Way".
(from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html)
# /usr/sbin/config MYKERNEL
# cd ../../compile/MYKERNEL
# make depend
# make
After doing so I realized I can build the new kernel the "New Way".
# cd /usr/src
# make buildkernel KERNCONF=MYKERNEL
# make installkernel KERNCONF=MYKERNEL
When the Traditional "make" finished I decided to use the "New Way" of building the kernel.
I was afraid that I would have to reinstall FreeBSD since I did both steps (Traditional and New).
Expecting my box to crash upon reboot I was very surprised to find that the "New Way" build superceeded the "Traditional Way" and my box booted with the kernel changes in affect.
This is just a note letting users know that that since I didn’t reboot after the changes of the "Traditional Way" that the "New Way" takes precedence.
David Huffstutler wrote:
> This is just a note letting users know that that since I
> didn’t reboot after the changes of the "Traditional Way" that
> the "New Way" takes precedence.
It’s not so much that it takes precedence as that it happened last.