<Guide at post #19> FreeBSD concise updating guide request

dcbdbis

dcbdbis

Good Afternoon,


Working with FreeBSD in a VM until I can get my system maintenance skills down. Before you flame, I'm old. Yes I read. Yes I have extensive source code building experience (Gentoo linux).

I am using the "www.freebsdmadeasy.com" as my guide. It's for the 6.* series of FreeBSD, and I fear that it may be no longer 100% relevant for 8.1.

At issue is that I find the documentation for updating a Freebsd system confusing. I realize that there are many ways to update and rebuild an entire system from source, which I am wanting to do...

Other than the website mentioned, I do not find any concise guides that I will lead me step by step through a complete system upgrade/rebuild via source. I'm afraid that since my small strokes (I've had health issues)...my memory is not as reliable, thus my request for a step by stem type of guide from someone of experience.

I have not been able to successfully update a FreeBSD system using the online FreeBSD documentation. There are so many options it's too confusing to me.

If anyone has a procedure that they would be willing to share with me, or a different website that I'm not finding in google, I would be sincerely appreciative.


My Goal: To install the base FreeBSD system, then promptly update all the sources, rebuild the world, rebuild the kernel, and install the same. Then I'd like to be able to build the rest of the system on this current stable base.

The branch I'd like to track is the "stable" branch.

I'm sure the experienced FreeBSD community has several excellent methods. If someone would share these or provide me with a different website pointer I'd be appreciative.

Any assistance would be sincerely appreciated.


Sincerely,


Dave
 
The 'twelve steps' in /usr/src/Makefile should help as well, or a slight variation thereon that I posted earlier. This is for rebuilding kernel/world. Synching sources (csup(1)) and editing a kernel configuration file are not part of it. Advice: leave build flags well alone. FreeBSD is not an OS that benefits from tweaking the defaults into oblivion. It will just demolish a working system.
 
Tracking A Development Branch covers this. But as a quick overview:

# csup 8stable-supfile
(8stable-supfile has tag=RELENG_8)
# rm -rf /usr/obj/usr
# cd /usr/src
# make buildworld
(Add j=4 or higher if you have a multi-core CPU)
# make kernel KERNCONF=MYCUSTOMKERNEL
# shutdown -r now
(The Handbook says you should boot into single-user, but it's not required.)
# cd /usr/src
# make installworld
# mergemaster -Ui
# shutdown -r now
 
Will someone check my work please?

I am very appreciative for all the excellent responses. After reading all of them, and other documentation suggested in this thread, I have arrived at an amalgamated method. It's all in sequence.

Would someone please check out my work to ensure that I haven't missed a step?

Again, I would be very appreciative......



Dave


Code: 
//----------Begin Document

FreeBSD Installation and Update


Install the base system
Turn on dhcp.
Install the developer and the kern developer sets.


Install your favorite editor
# cd /usr/ports/editors/nano
# make clean install


Update the sources

# cd /usr/ports/net/cvsup-without-gui/
# make install 

# cd /usr/ports/sysutils/fastest_cvsup/
# make install 

Now you can select the fastest server
# fastest_cvsup -c us 


<In the steps below using cvsup, replace cvsup14 with the server of your choosing determined from running fastest_cvsup -c us.>

Add to /etc/rc.conf
sendmail_enable=”NONE”

Add to /etc/make.conf
CPUTYPE=core2
CFLAGS= -O2 -fno-strict-aliasing -pipe

Update the ports
# cvsup -L2 -g -h cvsup14.freebsd.org /usr/share/examples/cvsup/ports-supfile 

Update the system sources
# cvsup -L2 -g -h cvsup14.freebsd.org /usr/share/examples/cvsup/stable-supfile 

Rebuild the world
# cd /usr/src
# make buildworld 

If it fails then do this before you retry:
# cd /usr/obj
# chflags -R noschg *
# rm -rf * 


Rebuild the kernel
# cd /usr/src/sys/i386/conf
# cp GENERIC NEWKERNELNAME 

Now edit the kernel config of your name to your specifications. Don't forget to change the ident fields to match the name of your custom kernel config

# cd /usr/src 
# make buildkernel KERNCONF=NEWKERNEL
# make installkernel KERNCONF=NEWKERNEL 

Add this to your /etc/make.conf file
KERNCONF=NEWKERNELNAME

# shutdown -r now


Restart in single user mode.
Selection #4 of the boot prompt.


Mount your disks
# mount -u /
# mount -a -t ufs
# swapon -a 


Update some of the configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.
# mergemaster -p


Install the world
# cd /usr/src
# make installworld 


Update the rest of your configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.

# mergemaster

Enjoy a freshly updated and fully rebuilt system.
 
dcbdbis said:
Code: 
//----------Begin Document

FreeBSD Installation and Update


Install the base system
Turn on dhcp.
Install the developer and the kern developer sets.
Click to expand...

Update ports with portsnap(8) before installing any.

Code: 
Install your favorite editor
# cd /usr/ports/editors/nano
# make clean install


Update the sources

# cd /usr/ports/net/cvsup-without-gui/
# make install
Click to expand...

Obsolete. Use csup(1) instead.

Code: 
# cd /usr/ports/sysutils/fastest_cvsup/
# make install 

Now you can select the fastest server
# fastest_cvsup -c us

<In the steps below using cvsup, replace cvsup14 with the server of your choosing determined from running fastest_cvsup -c us.>

Add to /etc/rc.conf
sendmail_enable=”NONE”

Add to /etc/make.conf
CPUTYPE=core2
CFLAGS= -O2 -fno-strict-aliasing -pipe
Click to expand...

Messing with CFLAGS is a recipe for failure. Do not set your own CFLAGS, leave them alone.

Code: 
Update the ports
# cvsup -L2 -g -h cvsup14.freebsd.org /usr/share/examples/cvsup/ports-supfile
Click to expand...

Use csup(1), not cvsup.

Code: 
Update the system sources
# cvsup -L2 -g -h cvsup14.freebsd.org /usr/share/examples/cvsup/stable-supfile
Click to expand...

-L2 -g is not needed.

Code: 
Rebuild the world
# cd /usr/src
# make buildworld
Click to expand...

Using multiple jobs with the -j flag can speed up builds on multi-core machines.

Code: 
If it fails then do this before you retry:
# cd /usr/obj
# chflags -R noschg *
# rm -rf *
Click to expand...

Deleting /usr/obj makes for faster builds. Might as well do it every time.


Code: 
Rebuild the kernel
# cd /usr/src/sys/i386/conf
# cp GENERIC NEWKERNELNAME 

Now edit the kernel config of your name to your specifications. Don't forget to change the ident fields to match the name of your custom kernel config

# cd /usr/src 
# make buildkernel KERNCONF=NEWKERNEL
# make installkernel KERNCONF=NEWKERNEL
Click to expand...

Again, the kernel target is the same as buildkernel and installkernel. Why use two steps when one is adequate?

Code: 
Add this to your /etc/make.conf file
KERNCONF=NEWKERNELNAME
Click to expand...

Unnecessary, since you're specifying the name in the kernel steps above.

Code: 
# shutdown -r now


Restart in single user mode.
Selection #4 of the boot prompt.


Mount your disks
# mount -u /
# mount -a -t ufs
# swapon -a
Click to expand...

Polite, but not necessary.

Code: 
Update some of the configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.
# mergemaster -p


Install the world
# cd /usr/src
# make installworld 


Update the rest of your configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.

# mergemaster
Click to expand...

The -Ui options will save a lot of time.
 
Latest rev of my guide

Code: 
FreeBSD Installation and Update


Install the base system
Turn on dhcp.
Install the developer and the kern developer sets.


Get the lastest fresh ports
# portsnap fetch
# portsnap extract
<subsequent runs will use the “# portsnap update” paradigm>.


Install your favorite editor
# cd /usr/ports/editors/nano
# make clean install

Add to /etc/rc.conf
sendmail_enable=”NONE”

Update the system sources 
# csup -L2  -h cvsup14.freebsd.org /usr/share/examples/cvsup/stable-supfile 

Rebuild the world
# cd /usr/src
# make buildworld 

Practice good housekeeping between runs or in case of failure
# rm -rf /usr/obj

Rebuild the kernel
# cd /usr/src/sys/i386/conf
# cp GENERIC NEWKERNELNAME 

Now edit the kernel config of your name to your specifications. Don't forget to change the ident fields to match the name of your custom kernel config.

# cd /usr/src 
# setenv KERNCONF Daves
# make buildkernel
# make installkernel


# shutdown -r now


Restart in single user mode.
Selection #4 of the boot prompt.


Mount your disks
# mount -u /
# mount -a -t ufs
# swapon -a 
Update some of the configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.
# mergemaster -Ui


Install the world
# cd /usr/src
# make installworld 


Update the rest of your configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.

# mergemaster -Ui



Enjoy a freshly updated and fully rebuilt system.
 
THANK YOU! And a couple of clarification requests

In Gentoo, the CFLAGS were key to having the entire system built to a particular architecture to take full advantage of the hosts CPU natively. I read clearly in your reply that doing so in FreeBSD is to ask for disaster. I certainly do NOT want that. Understood and I will comply. But...Is there a different method by which one may be able to build the entire system for a specific CPU and be stable?, or should I just leave this one alone?


And as regards to make buildworld......forgive me, Gentoo's equivalent rebuilt everything. The system and all installed software with it. If I understand correctly, that in the FreeBSD world that the system is what gets built with the 'make buildworld' command, and that the ports have to be handled separately.

Do I understand this correct? That is that buildworld is only for the system, and does not include installed ports? It's not an issue, I just don't want to duplicate any work, and my personal howto guide will reflect that information.

Again, a sincere thank you for the assistance.


Dave........
 
dcbdbis said:
In Gentoo, the CFLAGS were key to having the entire system built to a particular architecture to take full advantage of the hosts CPU natively. I read clearly in your reply that doing so in FreeBSD is to ask for disaster. I certainly do NOT want that. Understood and I will comply. But...Is there a different method by which one may be able to build the entire system for a specific CPU and be stable?, or should I just leave this one alone?
Click to expand...

CPUTYPE is safe enough, just avoid changing CFLAGS.


And as regards to make buildworld......forgive me, Gentoo's equivalent rebuilt everything. The system and all installed software with it. If I understand correctly, that in the FreeBSD world that the system is what gets built with the 'make buildworld' command, and that the ports have to be handled separately.
Click to expand...

Yes. FreeBSD has a very sharp distinction between the operating system and applications that may be added later.
 
On updating the ports......is this the best method?:

cd /usr/ports/<cat name>/<prog name>
make deinstall

---iterate through all ports to be updated---

followed by:

portsnap fetch update

then rebuilding them individually?

Or is there a method to do them enmasse?

The reason for the question, is I'll build a shell script as I add stuff to the system that will do this for me if no such enmasse build mechanism exists.

Thanks!


Dave
 
I would start by having an current make.conf, like

# cp /usr/share/examples/etc/make.conf /etc/

Then go and edit there:
- If you wish, uncomment and change the CPUTYPE (do not forget to leave the ?= in there!) This is indeed about the only optimization tweaking you may want to do and it only has very minimal effect -- especially with more recent CPUs where they are almost identical with regards to instructions..
- uncomment the SUP* variables. If using portsnap you may leave PORTSSUPFILE commented.
- add KERNCONF=YOURKERNEL. Again, for most usages, the GENERIC kernel is more than adequate. Anything, that is not already there may be loaded via kldload (or it loads automagically when needed)

Read /usr/src/UPDATING -- the last section of that file outlines what you need to do in order to upgrade (various scenarios);

To update your OS source

# cd /usr/src
# make update

To update your ports tree

# cd /usr/ports
# make update

Note, that if you used portsnap to populate the ports three, it will be used again. If you uncommented PORTSSUPFILE in /etc/make.conf it will use csup. You don't have to remember long commands -- this is for computers :)

For upgrading installed ports and installing new ports, you may use either ports-mgmt/portupgrade or ports-mgmt/portmaster. The later is sort of simpler, and seems more preferred recently. Both tools have their strengths and weaknesses (you may use both, but it takes time to master which one is better for which task).I recently switched to portmaster, because it doesn't install much bloat such as ruby etc. Less bloat, less things you need to care about, leads to easier system administration.
 
dcbdbis said:
On updating the ports......is this the best method?:

cd /usr/ports/<cat name>/<prog name>
make deinstall

---iterate through all ports to be updated---

followed by:

portsnap fetch update

then rebuilding them individually?
Click to expand...

No, way too much work and it will miss dependencies that need to be updated.

See Upgrading FreeBSD Ports.
 
wblock:

Thank you very much for the link. That's exactly the guide I'm looking for.

So for my system, other than the new link that I need to copy off into my personal step by step guide.....do I have a sound method for a base system update?
 
wblock:

I would like to comment on one item in your guide "For an idea of when the last update happened, look at the most recent file in /var/db/pkg"

This is NOT sufficient. You need to know, when you last updated your ports tree, not when you last updated/installed a port. This is because, it is the difference in the ports definitions that matter. You may have updated your ports three say on 2010-05-01 and then rebuilt/installed/whatever ports on 2010-09-20. Then, on 2010-11-05 you decide to follow your procedure.. and ignore all relevant information in /usr/ports/UPDATING between 2010-05-01 and 2010-09-20!

The proper approach is to check the last entry in /usr/ports/UPDATING (it's on top, so easy), make note of that date and after running portsnap, check all entries that have appeared since. Another way is to save copy of /usr/ports/UPDATING, then after portsnap, just diff the two files and follow all instructions in the diff :)

I used to do what you suggest, but was bitten few times badly --- so more attention now.
 
danbi said:
wblock:

I would like to comment on one item in your guide "For an idea of when the last update happened, look at the most recent file in /var/db/pkg"

This is NOT sufficient. You need to know, when you last updated your ports tree, not when you last updated/installed a port.
Click to expand...

I agree, but haven't come up with a better automated way to find out when ports were last updated.

The proper approach is to check the last entry in /usr/ports/UPDATING (it's on top, so easy), make note of that date and after running portsnap, check all entries that have appeared since. Another way is to save copy of /usr/ports/UPDATING, then after portsnap, just diff the two files and follow all instructions in the diff :)
Click to expand...

Well, not all the instructions, just the ones that apply. But how do you get people to do that kind of record-keeping when just getting them to read UPDATING is difficult?
 
I appreciate all of the useful information I have received from everybody. THANK YOU!

I have been able to build a good guide from this information!

Appreciatively,


Dave.
 
[SOLVED] The Resultant Updating Guide

This is certainly not the only way to get things done. But with the help of this forum, and especially wblock's proof reading assistance.....This is going to be the guide I use on every FreeBSD workstation I setup. and yes, I've tested it on non-critical machines after a fresh install.

I want to thank everyone involved for assisting me in developing my own personal updating guide.

//----------Begin Guide---------


FreeBSD Installation and Update


Install the base system
Turn on dhcp. [comment]// This is a personal choice of mine
Install the developer and the kern developer sets.[/comment]


Get the lastest fresh ports
# portsnap fetch
# portsnap extract
<comment]subsequent runs will use the “# portsnap update” paradigm>.[/comment]


Add to /etc/rc.conf
[text]sendmail_enable=”NONE”[/text]

[comment]Please be advised; this and the recommendation to enable DHCP depends on the situation. Disabling sendmail means you won't get daily log reports. It also means that if you don't use sendmail you will not get the apparent boot hang at “blanktime”[/comment]


Create a makefile
# cp /usr/share/examples/etc/make.conf /etc
[comment]<edit this file and set your options>[/comment]


Install your favorite editor if not 'ee'
# cd /usr/ports/editors/nano [comment]//This is my personal favorite. If you prefer 'ee', another good editor, skip this step.[/comment]

# make clean install


Update the system sources
# csup -L2 -h cvsup14.freebsd.org /usr/share/examples/cvsup/stable-supfile
[comment]// the server that you choose, be that cvsup2, or whatever is based upon your personal speed tests.[/comment]


Perform some housekeeping and then Rebuild the world
# rm -rf /usr/obj
# cd /usr/src
# make buildworld


Rebuild the kernel
# cd /usr/src/sys/i386/conf
# cp GENERIC NEWKERNELNAME

[comment]Now edit the kernel config of your name to your specifications. Don't forget to change the ident fields to match the name of your custom kernel config.[/comment]

# cd /usr/src
# setenv KERNCONF YOURKERNELNAME
# make buildkernel
# make installkernel
# shutdown -r now


Install the world
# cd /usr/src
# make installworld

[comment]Update the configuration files
Schedule plenty of time to carefully review the changes before you commit. Not paying attention to what is presented next can totally bork your system.[/comment]

# mergemaster -Ui





The base operating system has now been completely updated and rebuilt from source.



For any ports you may have installed, there is an outstanding guide for a fairly painless method to stay up to date at:
http://www.wonkity.com/~wblock/docs/html/portupgrade.html
 
I am old. I am not able to understand this formatting thing. What I posted I thought was very readible and clear.

My son (mid-thirties) is a network engineer and has extensive experience in some very large and mission critical data centers. He's more "in the know" than I am. I have asked him to review my posts and tell me what it is that is expected of me.

I have also PM'd the moderator of a differernt forum and asked for examples for me to follow. I am HTML illiterate.

For those of you who are upset by the formatting, I apologize.

I ask for your understanding as my son reviews and tutors me on what it is I'm being asked to do.


Dave....
 
OK folks.....

Did I get the formatting closer to what it should be?


Thanks!


Dave.............
 
To DutchDaemon,

After receiving some hand-holding....I think I may have the formatting at least better. Would you please review and let me know? If I work through getting this post correct, then I'll have it down.

Getting old really sucks! Don't do it!

Also, others have mentioned that they cannot PM me. I checked my settings and don't have anything blocked or turned off. So I added them to my contacts and we'll see if that works.

Anyway, please let me know if I have the formatting concept down properly, and if not....kindly give me an example of my mistake, and what it should look like and I will edit the post until I get my head wrapped around it.

I'm going to be deploying FreeBSD on several workstations both in old business contacts and friends. I will be their front line of support. I need to be able to post in the forums without angering folks.

Please advise,

Sincerely and respectfully,


Dave
 
dcbdbis said:
[comment]Now edit the kernel config of your name to your specifications. Don't forget to change the ident fields to match the name of your custom kernel config.[/comment]
Click to expand...
Just curious... something I was wondering about when I was reading the handbook, why is it really necessary or desirable to edit the kernel config to your specifications? If hardware changes or something like that, wouldn't it get you into trouble? I would prefer to have something generic as possible to minimize opportunities for errors to crop up. FWIW I was reading this when I had to patch some ZFS related stuff in 8.0 RELEASE.

I basically patched the files and did the following:
# cd /usr/src
# make clean && make buildworld && make buildkernel && make installkernel && make clean

Not sure if it was the right thing to do but things now appear to be working now. Have to upgrade to 8.1 because 8.0 is EOL though.
 
You must log in or register to reply here.
Back
Top