Update FreeBSD
Complete the installation, configuration, FreeBSD basically even if the pack is over. However, so far no general operating system can guarantee "Bug-free", FreeBSD also. After the reboot, we need to make some adjustments and, by reconfiguring the kernel, we can get a smaller, faster operating system.
The first step is to sync the source code. FreeBSD is an open source operating system whose entire source code can be synchronized with a central cvsup server, or one of its mirrors, through cvsup.
CVSup is an optional package, and it can also be installed from ports (/usr/ports/devel/cvsup and/usr/ports/devel/cvsup-nogui). Given that many applications rely on X's library files, I installed it in the previously installed section and installed the CVSup package directly. However, if you have the patience to make the required ports one by one, then installing Ports collection and then make Cvsup-nogui is a good idea, although it takes a long time.
Create a Supfile for CVSup (1), named Stable-supfile:
(The CVSup server selected in the default host- ftp.bjpu.edu.cn access to the IP is limited, the author only in Beijing University of technology used, so if you can not connect this server, please try www.cn.freebsd.org, or cvsup.freebsd.org)
*default host=ftp.bjpu.edu.cn
*default BASE=/USR
*default PREFIX=/USR
*default Release=cvs Tag=releng_4
*default Delete Use-rel-suffix
Src-all
Ports-all tag=.
subsequently executed
Cvsup-g-L 2 stable-supfile
Here you need to explain a little bit about the FreeBSD versions.
FreeBSD includes 3 types of branches:-release,-stable and-current. FreeBSD 3.x, 4.x, and 5.0 are currently maintained versions, and if you are looking to run stably, the latest version you can choose will be FreeBSD 4.6-stable ( If you are updated after the 4.6.2-release release, then it is actually newer than 4.6.2-release, and its formal CVS tag is releng_4, or FreeBSD 4-stable).
So what's the difference between the three types of branches?
The development of FreeBSD is very active. Some new features may be introduced in the system at any time. The latest code is introduced in the-current branch. -current changes are frequent and can be modified hundreds of of a day. Using the-current branch of FreeBSD requires patience and courage, as your system may collapse at any time (as the FreeBSD 5.0 is nearing the end of the development, this phenomenon is becoming less), and made world may return empty-handed ( There is no guarantee that the-current branch will compile properly, and this branch is not performing well (because of debugging, this branch introduces a lot of debugging options, which means it won't run too fast). Of course, like its name, the-current branch's version is also the latest 5.0, and all FreeBSD bugs and bug fixes are introduced first in the-current branch. Currently, the only remaining of the-current branch is FreeBSD 5-current (which specifies "." When CVS tag is specified), which includes the latest developments in the FreeBSD 5.0 development.
FreeBSD 5 introduces a large number of new features, including core-level threads (currently FreeBSD thread support is limited to user-level threading, which is not good enough in a multiprocessor environment, and of course, multi-process threading simulations currently supported with fork () can provide functionality similar to core-level threads. But not all programmers know how to use fork, complete soft Updates (this change will provide better file system performance while providing better stability), and so on. If you have a fast internet connection, a single or some spare machine (not a production server, of course), and you want to contribute to FreeBSD development, or you care about the latest development of the operating system, the-current branch is the best choice.
In addition, because the-current branch performance is not good, the stability is not enough such shortcomings, for the production of the server, usually run should be freebsd-stable. Like its name, Freebsd-stable's aim is to "run stably". Code in the-current branch, after a period of time (usually 7-90 days, but the security update is a special case, usually in a few hours), the code that conforms to the version condition (some of the new features can only be used for FreeBSD 5.0) is freebsd-stable absorbed, This operation is called MFC (Merge from-current, not Microsoft Foundation classes:p).
Since the first release of FreeBSD 5.0 has not yet been released, so far there is no 5.0-stable. Currently, the freebsd-stable has two versions, FreeBSD 3-stable and FreeBSD 4-stable, which correspond to the latest stable versions of 3.x and 4.x (the corresponding CVS tags are releng_3 and releng_4) respectively. Due to the replacement of the version, 3.x of the-stable is gradually disappearing. The average freebsd-stable modifies about 10 files per day.
Every once in a while, FreeBSD's distribution engineering group (release Engineering team) locks the freebsd-stable source code tree. During this time (the current rule is 30 days, before there are 30 days to prepare), all MFC operations need to issue the approval of the engineering team, so freebsd-stable will not introduce any new features at this stage. After this time, the release engineering team will lock the ports tree at the end and build a copy of all the package, after which the locked-stable may pass through several RC (Release Candidate), be named released, and CD-ROM issued.
As the name suggests,-release's design goal is "release." Once the release of a version, then his function will not be increased. After all, there is only one goal of maintenance, and that is absolute stability. If you sync with the-release branch, there will never be a situation where make cannot pass, and it usually ensures that your system is "absolutely" stable because it does not introduce any new features (for example, 4.6 is 4.6, and you have to explicitly specify 4.6.2 if you want 4.6.2 functionality).
Currently, FreeBSD has many release versions, and their CVS tag is as follows. I personally recommend using the latest 4.6.2-release.
For most people,-release is a more extreme choice. Whenever there is a version upgrade, if you want to follow up, it must be modified supfile, if you choose not to follow up, then you may cause ports work abnormalities. If updated frequently,-release can guarantee the security of the operating system itself, but like other branches, if ports problem, then also have a make, and since this, but also better use-stable.
If you meet the following criteria, the release branch may be better for you than the-stable branch.
The software you use is very sensitive to the changes in the operating system, for example, it can only FreeBSD 4.5, not run on 4.6, and you are not going to use its updated version, or its author refuses to update
- OS updates don't make any sense to you, for example, you intend to use FreeBSD as a relatively fixed embedded operating system, for example, as part of a firewall
- Updates can be a problem for you, and most of the new features of the operating system will not bring you anything other than adding to your annoyance.
-and, in accordance with all of the following conditions-
- You look at FreeBSD every day, and security bulletins for all the software you use
- Your Internet connection is quite smooth.
At present I maintain all the host, in addition to as a firewall, the use of freebsd-stable.
Once the source code is synchronized, the entire system should be updated. If you don't have the habit of checking your security bulletins every day, you should be concerned about what code CVSup has updated. Nectar is the current FreeBSD security officer. If you find him updating a lot of code all of a sudden, it's probably necessary for you to make the world and kernel immediately.
In order to update the entire system, execute in/USR/SRC
Make World
And
Make kernel kernconf= Kernel profile name
Of course, can also be linked up to execute:
Make World kernel kernconf= Kernel profile name
If your computer is running slowly, update the basic system (equivalent to a world that does not include a library)
Make most
It's a good idea to make the world, but makes world, because it ensures that changes to the C-run environment are applied to all programs, and that if the fix is not a dynamically connected C function library, make world guarantees code consistency.
Make kernel is an operation that requires a reboot. If your made world modifies key services for your system, it's best to reboot. I rarely have the patience to read the execution of make world and kernel, which takes one hours to one day depending on the speed of the system, and not all SSH clients can execute for long periods of time, for example, multiple versions of SECURECRT have a memory leak problem.
To solve this problem, I use the following command to complete the update:
Make World kernel kernconf= Kernel profile name clean >/var/log/world,out && reboot &
This command records the whole process of the update, and if the compilation fails, you can quickly find out why. For most people, because of the && of the back, you just have to look at uptime to see if it succeeds.
It should be explained that FreeBSD made world does not always succeed. Sometimes you need to modify some environment variables to successfully complete make. To ensure make is successful, it is recommended that you take a look at the specific requirements in the updating (this requirement is not available at FreeBSD release, and many times it will be introduced in a current/usr/src) before performing any made operations in the. Then, as MFC enters the-stable branch, and before a large version upgrade (across release or even the major version number), execute the following command first
Mergemaster-p
and executed after make world
Mergemaster-i
Running Mergemaster scripts requires a certain UNIX configuration knowledge, however, because the configuration file contains a lot of help information, so long as MASTER.PASSWD, group such files do not have a big problem ( If CVSup updates master.passwd, then you need to be careful, because the MASTER.PASSWD standard configuration is that the root password is empty, then it needs to be merged with M instead of the I installation, and Mergemaster won't introduce any new problems.
The previous command is the configuration of update make (/etc/defaults/make.conf and/etc/make.conf). For most people, this is generally not necessary unless you are upgrading across versions. The latter command synchronizes all configurations and installs previously nonexistent profiles without prompting.
I have encountered FreeBSD because the system date is not correct and can not make, so, again, specifically remind everyone, if your system date is incorrect, it is best to use the date command to modify, or simply use Ntpdate or ntpd to sync time. about how to use NTP will be described later.
Later we will explain the configuration of the FreeBSD kernel and how to configure make.conf to optimize the FreeBSD compilation results.