Upgrading FreeBSD from and to

As often happens, having hooked on a seemingly small topic, with the desire to quickly learn everything and set everything up, you have to dig in the dense wilderness and read more than one article and / or manual. So I did this time. Initially, there was a desire to simply learn how to update ports (or source texts of ports) so that if you wish, install non-outdated software, but you had to dig a little deeper.
This article is intended only for newbies in FreeBSD, experienced pros here generally nothing new, I think, will not find for themselves. Therefore, if you are on “you” with this system, you can safely skip further text.
There is enough information on this topic, but from 6-10 notes and articles I took, so to say, the best practices and experience, and wrote them in one, with links to more complete articles, so if you want you can get more detailed information on each item .
The content of the article:
1) The choice of software for updating the source code.
2) The process of updating system sources and ports.
3) System upgrade (core and world).
4) Upgrading ports with pkg_ *, portupgrade, portdowngrade.
5) Conclusion
6) Additional literature.

Choosing software to update the source code

So, when updating the source code, I selected 2 subsections - these are the source codes of the system and the source texts of the ports.
1) When updating the system sources, you can use either the CVS or SVN repository. SVN is a newer development and is intended to replace the outdated cvs, respectively, svn has a wider functionality when working with versions of the source code. But since I use FreeBSD as a gateway and I don’t intend to update the system every few days, I decided to stop at the good old cvs, because svn requires you to install not a small amount of additional software, but I did not see global advantages for my tasks in svn. To work with the cvs repository, the csup utility will be used (the same as cvsup but written in C), included in the standard composition of freebsd, that is, you don’t need to add anything (update via SVN is discussed in the additional literature at the end of the article).
2) Updating of sources for ports is possible only from the CVS repository, for this you can use either csup or portsnap. Portsnap is the recommended port update system and it is also pre-installed on the system, and we will use it.

The process of updating system sources and ports.

Configure csup to update system sources.

To configure the update settings, create the / etc / supfile file:
*default host=cvsup6.ru.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs
*default delete use-rel-suffix
*default compress
#*default release=cvs tag=RELENG_8_1_0_RELEASE
*default release=cvs tag=RELENG_8
src-all

tag examples for the src-all tree:
RELENG_8 - FreeBSD 8-STABLE Branch
RELENG_8_1 - A FreeBSD 8.1 branch to which security patches go
RELENG_8_1_0_RELEASE - “Frozen” snapshot of the state of the FreeBSD 8.1 code at the time of its release

Everything is ready, we launch the update:
# csup -L 2 /etc/supfile
You can add the -z key (compression) to save traffic.
')
If the configuration file has just been created, and this program has never been used before, then you can start worrying about whether everything goes well ... There is an easy way to try it out without affecting your precious files. Just create an empty directory somewhere and place it as an additional command line argument:
# mkdir /var/tmp/dest
# cvsup supfile /var/tmp/dest
The specified directory will be used as the destination of all updates. CVSup will work with files from / usr / src, but will not change or delete them. Instead, all file updates will be placed in / var / tmp / dest / usr / src. When launched in this way, CVSup will also leave the base directory untouched. New versions of these files will be written to the specified directory. If you have read permissions to the / usr / src directory, you do not even need to work as root to perform a trial upgrade.

Updating ports through portsnap

For the first run:
$ portsnap fetch
$ portsnap extract
For all subsequent launches:
$ portsnap fetch
$ portsnap update

Fastest cvsup

The fastest_cvsup utility task is to find the server with the CVS repository that is optimal in terms of access speed.
$ cd /usr/ports/sysutils/fastest_cvsup/
$ make install clean & rehash
Application:
$ fastest_cvsup -q -c ru

System update (core and world), theory.

Suppose we set up a freshly baked FreeBSD 8.1-RELEASE, and we wanted to upgrade it to the FreeBSD 8-STABLE branch. We need to synchronize the source texts that we have on the disk, with the repository - download the new parts.
The sequence of actions is as follows:
1) make up the supfile and put the list directive in it. In which we specify under what name the checkouts file should be saved:
src-all tag = RELENG_8_1_0_RELEASE list = RELENG_8
2) We perform the first synchronization with the command (#csup -L 2 / etc / supfile), with the frozen branch of our release RELENG_8_1_0_RELEASE
3) Remove the list directive from our supfile:
src-all tag = RELENG_8
4) we carry out the second synchronization with the RELENG_8 branch - we update the sources to STABLE

The essence of the idea is as follows: when csup is running, it uses checkouts files to compare information about file versions on the local disk and on the server, and to synchronize only those that have changed. Immediately after installing the system, in the / var / db / sup directory there are no checkouts of files for collections synchronized by us yet. The trick is to create them first. Since we have release 8.1 and the source is installed from it, then after the first “synchronization” with the “frozen” tag of the same release RELENG_8_1_0_RELEASE we will be able to build up-to-date checkouts files. The first synchronization is essentially nothing to synchronize, but only enumerates files on the disk and in the repository, and builds a database - the checkouts file. After the first synchronization, we will get the subdirectory src-all in the / var / db / sup directory.
It will have a file named checkouts.cvs: RELENG_8 - because we specified this in the list directive. As soon as we start the second synchronization with the server, csup will know exactly which versions of the files should be transferred and what should be removed. Synchronization will be cleaner, take less time and require less traffic.

Obnolven system (core and world), prkatika.

uname –v - find out the current kernel version
uname –r - find out the current version of the system
The update is best divided into 2 parts, the build is a compilation of the source code and further installation. It’s not often necessary to do this, for me, it’s best to do everything schematically, it’s easier to catch possible jambs.

I) Build

1. The core
1) cd /usr/src/
2) rm -R /usr/obj/*
(If during the deletion you get errors regarding the set flags, then you need to run the command #chflags -R noschg * )
3) make clean && make clean
4) make -sj4 buildkernel KERNCONF=YOUR_KERNEL_HERE
(YOUR_KERNEL_HERE is the name of the kernel that is in the / usr / src / sys / i386 / conf folder. But note that you do not specify the path, but only the file name. I advise you to rename the file so that it compiles the new kernel systems)
Where j4 is to compile in 4 threads. Recommended for single-processor machines, since compilation is more demanding on the I / O system rather than the processor. For multiprocessing this value can be increased. s - reduces the amount of information displayed on the screen.)

2. World (system)
1) cd /usr/src/
2) rm -R /usr/obj/*
3) make cleandir && make cleandir - (make cleandir recommends a handbook twice)
4) make -sj4 buildworld

Ii) Installation

1. The core
1) make installkernel KERNCONF=YOUR_KERNEL_HERE
2) reboot
2. World (system)
The world is a custom program - like: grep, awk, sh, chmod, and others. In short everything that is not included in the kernel and kernel modules. Before building it is recommended to return to the standard view /etc/make.conf. In case of problems, if something is not going to be installed or not installed, it is worth seeing what is there and remove the excess.
In the process of installing the world, ideally you need to run the program mergemaster. This program determines the difference between your configuration files in the / etc directory and the configuration files from the / usr / src / etc source tree. This is the recommended way to synchronize system configuration files with those located in the source tree.
To rebuild the world, it’s better to enter single-user mode:
1) mount -u /
2) mount -a
3) rm -R /usr/obj/*
4) /usr/src/usr.sbin/mergemaster –p
If there are differences, a message appears on the screen about it.
The first line in it is the name of the file that does not meet the new requirements, and below are the differences themselves.
The "-" marks the lines that the utility is going to delete,
and "+" - to be added.
At the end, the following options are offered:
d - remove the proposed option and leave the old one;
i - install the proposed option by deleting the old one;
m - compare line by line the old and the proposed option;
v - see the differences in the files again.
5) cd /usr/src/
6) make installworld
7) mergemaster
8) reboot
9) cd /usr/src/
10) make delete-old

Upgrading ports with pkg_ *, portupgrade, portdowngrade.

1) #portsnap fetch update - update ports.
2) # pkg_version -v | grep “need” # pkg_version -v | grep “need” - Displays a list of ports that need to be updated.
3) #pkg_create -b port_name - Ability to create packages for the desired ports and then install via pkg_add
4) #pkg_add -i -f port_name.tbz - Installing the package without dependencies. After this installation, the easiest way to roll back to the previous version.

Using the portupgrade utility

You can find it here - / usr / ports / ports-mgmt / portupgrade
1) portupgrade -nr port_name - displays detailed information about the future installation of the package (which files and dependencies will be updated)
2) portupgrade -ir port_name
The -i switch indicates that the user is polled when upgrading in cases where there are selections (yes / no).
The -r switch specifies to update the downstream port dependency chain.

When upgrading using portupgrade, an important trump is the configuration file /usr/local/etc/pkgtools.conf, which contains the parameters passed to the port during assembly (MAKE_ARGS hash). It is useful to edit such settings in this file to fit your needs and subsequent updates will take place without any problems.
Also, the necessary parameters can be torn out in case of reinstalling the port or when upgrading to a new version, and this is useful to maintain compatibility between the servers. For example, a lot of nerves can kill the differing encoding of the installed mysql when transferring a site between servers.
There are cases when it is necessary to forbid updates for a specific port. The names of such ports can be specified in the HOLD_PKGS hash in the pkgtools.conf file, for example, so we prohibit updating the midnight commander:
HOLD_PKGS = [
'mc-*',
]

Portdowngrade utility

Allows you to roll back to the previous version.
Installation:
# cd /usr/ports/ports-mgmt/portdowngrade
# make DEFAULT_CVS_SERVER="anoncvs@anoncvs1.FreeBSD.org:/home/ncvs" install clean

Using:
#portdowngrade port_name - displays a list of previous versions of the port and allows you to select and install the desired version.

Conclusion

This is the manual for the full FreeBSD update. I just study this OS for this I do not pretend to discover something new, but personally it is much more convenient for me to use one article than the 5th, 6th, etc. for each separate utility, I composed this manual for myself, but maybe it will also prove useful to someone!

Literature

Version Control in Subversion
Source Update: cvsup, csup, svn, portsnap
Using csup
Examples of finer source control
Additional information on the launch of mergemaster
portdowngrade - roll back the desired port to any earlier version
portupgrade - `update` installed ports.