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



## dcbdbis (Dec 1, 2010)

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


----------



## rusty (Dec 1, 2010)

http://blog.up-link.ro/freebsd-how-to-upgrade-freebsd-7-to-8-stable-release/ gives some decent instructions in using cvsup to ugrade sources.
The handbook covers alot of Rebuilding World or once you have pulled in sources you can also find instructions towards the end of /usr/src/UPDATING.


----------



## DutchDaemon (Dec 1, 2010)

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.


----------



## wblock@ (Dec 1, 2010)

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`


----------



## UNIXgod (Dec 2, 2010)

This is also a very good document to read. It is up to date as well. 

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html

here is an old cheat sheet I have:

https://forums.freebsd.org/showpost.php?p=5526&postcount=14


----------



## dcbdbis (Dec 2, 2010)

*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



```
//----------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.


----------



## wblock@ (Dec 2, 2010)

dcbdbis said:
			
		

> ```
> //----------Begin Document
> 
> FreeBSD Installation and Update
> ...



Update ports with portsnap(8) before installing any.



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



Obsolete.  Use csup(1) instead.



> ```
> # cd /usr/ports/sysutils/fastest_cvsup/
> # make install
> 
> ...



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



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



Use csup(1), not cvsup. 



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



*-L2 -g* is not needed.



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



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



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



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




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



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



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



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



> ```
> # shutdown -r now
> 
> 
> ...



Polite, but not necessary.



> ```
> 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
> ...



The -Ui options will save a lot of time.


----------



## dcbdbis (Dec 2, 2010)

*Latest rev of my guide*


```
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.
```


----------



## dcbdbis (Dec 2, 2010)

*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........


----------



## wblock@ (Dec 2, 2010)

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?



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.



Yes.  FreeBSD has a very sharp distinction between the operating system and applications that may be added later.


----------



## dcbdbis (Dec 2, 2010)

*Error in Post #8 has been corrected*

Fyi


----------



## dcbdbis (Dec 2, 2010)

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


----------



## danbi (Dec 2, 2010)

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.


----------



## wblock@ (Dec 2, 2010)

dcbdbis said:
			
		

> On updating the ports......is this the best method?:
> 
> cd  /usr/ports/<cat name>/<prog name>
> make deinstall
> ...



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

See Upgrading FreeBSD Ports.


----------



## dcbdbis (Dec 2, 2010)

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?


----------



## danbi (Dec 2, 2010)

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.


----------



## wblock@ (Dec 2, 2010)

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.



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



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?


----------



## dcbdbis (Dec 2, 2010)

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.


----------



## dcbdbis (Dec 4, 2010)

*[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


----------



## dcbdbis (Dec 4, 2010)

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....


----------



## graudeejs (Dec 4, 2010)

A link to your Howto would be enough  Instead of double posting....
Also if you update howto, and forget to update this thread, someone who reads this, won't read updates....

So I suggest you delete content of http://forums.freebsd.org/showpost.php?p=113084&postcount=19 post
and instead insert link to your howto: http://forums.freebsd.org/showthread.php?t=19905


----------



## dcbdbis (Dec 4, 2010)

OK folks.....

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


Thanks!


Dave.............


----------



## dcbdbis (Dec 4, 2010)

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


----------



## DutchDaemon (Dec 4, 2010)

Pretty sure http://forums.freebsd.org/showthread.php?t=8816 covers the formatting quite concisely ..


----------



## carlton_draught (Dec 7, 2010)

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]_


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.


----------



## wblock@ (Dec 8, 2010)

carlton_draught said:
			
		

> 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.



Building a custom kernel lets you remove devices you'll never use, or set options that can only be built into a kernel.  It's not a huge risk, since most modules can be loaded at runtime if you unexpectedly need them.



> `# cd /usr/src`
> `# make clean && make buildworld && make buildkernel && make installkernel && make clean`



That's a shortened version of the normal update procedure, which includes a reboot after installing the new kernel to make sure it works.  A reboot after that is needed to load the new world, too.


----------



## UNIXgod (Dec 8, 2010)

carlton_draught said:
			
		

> 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.



The 8.7 If Something Goes Wrong section in the manual is pretty self explanatory. Even has one of those nifty "best practices" blocks. 

http://www.freebsd.org/doc/handbook/kernelconfig-trouble.html

It should state that your last kernel is saved as kernel.old. When you move your drive to another machine just go back to GENERIC and reconfigure.


----------



## carlton_draught (Dec 8, 2010)

Thanks wblock and UNIXgod. I might even give it a go. It was just a bit more than I wanted to do at the time, that's all. My immediate priority was being able to backup my system, which I could not do at the time because zfs send/receive was giving me "Argument List Too Long" errors. I didn't want to compound things by rendering my system completely unusable, even if the fear was unfounded.


----------



## UNIXgod (Dec 8, 2010)

carlton_draught said:
			
		

> Thanks wblock and UNIXgod. I might even give it a go. It was just a bit more than I wanted to do at the time, that's all. My immediate priority was being able to backup my system, which I could not do at the time because zfs send/receive was giving me "Argument List Too Long" errors. I didn't want to compound things by rendering my system completely unusable, even if the fear was unfounded.



Well I don't want to get in trouble for losing someone else's data . If you have an opportunity to practice on a clean machine first it might help. If you can't do that recompile GENERIC first and make sure you cp the files yourself and name it something like kernel.works, kernel.bak, or kernel.gen. It shouldn't matter what the name is as long as you remember it.

If your really paranoid go through the process of loading the cp'd kernel as if you had to. Once you go through that process and see it work move to the step of compiling your own kernel.

NOTE: Most of us( if not all) botch the kernel when we are new. Especially on the first try. It's a process much like anything else you grok in FreeBSD. If you do get stuck it's more important to figure out what went wrong vs fear and not doing it.

You are correct though. backups are important to know and probably should be considered a priority over everything else. 

When you are ready to compile your kernel start a new thread and I would be more than happy to help you with grokking the config and maybe save you one less headache.


----------



## carlton_draught (Dec 8, 2010)

Thanks very much UNIXgod. I may indeed take you up on that offer.

You are right about grokking things in FreeBSD, you have to be able to experiment on an install you can afford to hose first. You have to feel ok with destroying your system otherwise you are too scared to learn properly. Fortunately I have backup and restore procedures worked out, tested and documented such that I can afford to hose my system. It has taken me months to get to this point. I will hopefully post them soon.

I did forget that I don't just need to update ports, I also need to update the kernel and "world" I guess, for security reasons if nothing else. So I will probably have to amend the procedures, but that's just life. Not sure whether I should do a fresh install of FreeBSD 8.1 versus upgrading. I've long been an install from scratch person from my Windows days, but if there is little that can go wrong I'll try upgrading. Anyway, thanks again.


----------



## danbi (Dec 8, 2010)

You don't have to update kernel and world when you update ports.

The operating system and applications (for example ports) are distinct on FreeBSD. It is very rare when a port upgrade might require OS (kernel + world) upgrade. It is also possible to need to upgrade (some) ports after you upgrade the OS, especially if version number changes (some ports have the bad habbit to keep directory threes named after the OS version).

It is ok to follow the stable branch, which means that if you curently run FreeBSD 8.0-release recompiling and reinstalling today would bring you to 8.2-prerelease. It is safe, as long as you follow the instructions in the /usr/src/UPDATING file.

There is little point to do 'clean' install, because unlike Windows, FreeBSD does not collect garbage in 'the registry'. If anything is left, it's from ports and the OS has nothing to do with it. When you do large updates however, such as from 8.0 to 8.2, there might be number of files and libraries that are no longer current and you may wish to remove. These can be discovered with 

`# cd /usr/src`
`# make check-old`

instead of check-old, you may also use check-old-dirs, check-old-files, check-old-libs
Beware, that you should make sure nothing is using the old libs. The OS files will not, but it is likely that an port compiled on the old system may reference some old library (they should not but... that's different story). But, if you recompile all your ports after upgrading the OS, you may delete the old libs with 

`# cd /usr/src`
`# make delete-old-files`
`# make delete-old-libs`

The first make will delete old files (manpages, executables, configuration files) that are no longer neccesary. The second make will delete the old libraries.


----------



## danstoner (Dec 9, 2010)

*yay for guides*

Dave,

Thank you for asking this question and for posting your guide.

As a sysadmin coming from a Linux background into a new job supporting FreeBSD machines, I had a really hard time "getting it" that there is a distinction between the tiny amount of base software included in FreeBSD and the much larger blob of software that most people probably have on their systems to make them useful.


----------



## carlton_draught (Dec 12, 2010)

UNIXgod said:
			
		

> When you are ready to compile your kernel start a new thread and I would be more than happy to help you with grokking the config and maybe save you one less headache.


I've taken you up on this offer here. If I'm lucky I will get things working by myself, but either way, maybe it will help someone else. Thanks to everyone on the thread who has posted, I appreciate it.


----------



## carlton_draught (Mar 20, 2011)

I thought I would post my own notes on the process, in case it helps someone, or if I'm doing something questionable then someone more knowledgeable can offer some insight. Note that this all should be able to be derived from the handbook. Even when I point to bits where I've walked through it, I've linked to appropriate parts of the handbook.

This assumes that you are installing from ports (not packages), and using ports-mgmt/portmaster to manage your ports. It also assumes that you are tracking RELEASE (when it comes to world/kernel, which is completely distinct from ports).

Ports
*Setup procedure:*

Install ports-mgmt/portmaster.
`# cd /usr/ports/ports-mgmt/portmaster`
`# make install clean`
Configure portmaster. The arguments for the lines I uncomment are -b, -g, -d, -m, -w, --no-confirm.
`# vi /usr/local/etc/portmaster.rc`
Copy DutchDaemon's portupdater.sh script to somewhere like root/bin.
`# mkdir /root/bin`
Paste it in there.
`# chmod 700 /root/bin/portupdater.sh`
*Maintenance frequency:* daily
*Maintenance procedure:*

`# /root/bin/portupdater.sh yes`
Read the output, do as it says. Pay close attention to /usr/ports/UPDATING warnings, these need to be followed if you use a port corresponding to a warning.
If you are keeping on top of ports updating, it's effective to use the -a option.`# portmaster -a` (or # portmaster portdir/port, if you want to do particular ports first.)
Sometimes if you are having difficulty, you will need to go to the port directory and do something like:
`# make deinstall`
`# make reinstall clean`

Documentation Set
*Setup procedure:* None
*Maintenance frequency:* weekly?
*Maintenance procedure:*
Replace "cvsup.wherever.FreeBSD.org" with a a nearby mirror.
`# csup -h cvsup.wherever.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile`


World (includes kernel, sources and system binaries), aka Base System
*Setup procedure:* My thread goes over it here.
*Maintenance frequency:* weekly?
*Maintenance procedure:*

Update the sources. If nothing is new, this is all you have to do.
`# csup /root/supfile`
If something has changed, then make a backup (my way is shown here). And then I walk through the steps in the next post.


----------

