I prefer to use the -STABLE branch which means there are many more updates compared to RELEASE. I try to do an update once a week or at least a couple times a month. This is not a particularly difficult task but I still refer to a printout of a tutorial page from an old BSD Now podcast. I have a number of customizations which I have used in the past along with a custom kernel, but I have not used them lately, or at least not the customized KERNCONF. This entire process will need to be done as root due to standard default permissions.
** Please note that FreeBSD switched to git and so svn is not the method since Dec 18th 2020 or so. **
If you have not done so already, you will need to obtain the source for the build you intend to use.
git clone -b master --single-branch --depth 1 git://github.com/freebsd/freebsd.git /usr/src
and then to prepare now for future updates do:
git config pull.rebase true
Since I use the stable branch of version 12, below is how I obtain a specific branch:
git clone -b stable/12 --single-branch --depth 1 git://github.com/freebsd/freebsd.git /usr/src
Assuming you hadn't just completed the above, or sometime next week you choose to rebuild, one of the first steps is to update /usr/src. This can be as easy as changing to the directory /usr/src then type git pull. Either before or directly after this step, it is very important not to have any leftover remnants from the previous builds, use the command make cleanworld, and then to be sure, the command make clean, prior to any building.
Now that the preparations have been made, we can begin. You can take advantage of multiple cores in your system by setting one job per core or cpu. If you are uncertain you can check by sysctl -n hw.ncpu and place the resulting number after -j for the number of jobs. Wow, I just realized that I hadn't used all my six cores the last time I rebuilt my kernel and world. I would have had I used the command below, because it will always provide the correct number, supposing I have 8 cores sometime in the future I wouldn't be using only six for the build.
make -j `sysctl -n hw.ncpu` buildworld
Now that that is complete, I can do the next step. This one I discovered can be combined with the step after it, as below. This explicitly defines the kernel configuration file, which must reside in /usr/src/sys/amd64/conf as a real fle, or a symlink to it from your home directory which is a good way to keep it against accidental erasure. By using kernel rather than buildkernel the scripts involved will build and install the kernel in the default location, so this is particularly helpful if the process is unattended such as a slow task handled while the admin is sleeping or handling other matters.
make -j `sysctl -n hw.ncpu` kernel KERNCONF=GENERIC
Although I have had a custom kernel in the past, and I still have the modified kernconf file, I am using GENERIC because shockingly, I had some difficulties. My troubles with booting and with kernel builds have been primarily related to graphics. I think I have a decent handle on them now, but rather than use the monolithic configuration I made, I want to take a closer look at how it compares to GENERIC and also discover which items can be built as kernel objects. Once I know that, I would limit kernel object builds to those I need or might use, and reduce rather than increase the kernel by removing things I never use.
The next step is to go to single user. This I do with a reboot which also verifies that the kernel I just installed functions as intended to that point.
reboot
Watch for the FreeBSD startup menu, press space as needed to pause it -- it may be set to be a very short countdown here, then choose 'singleuser' by hitting '2'. It is NOT recommended to use another shell for handling the buildworld or buildkernel processes, so when it finishes and shows the prompt below, tap the return or enter key.
Enter full pathname of shell or RETURN for /bin/sh
As I mentioned in another blog post, now I can't boot the way to access /usr/src again requires some mounting actions, below mounts all items in /etc/fstab as read-write.
mount -u /
and then if your system is ZFS rather than UFS, this mounts all datasets:
zfs mount -a
Once in /usr/src there are a few more things to do and then we can reboot into the new system. First, what the manpage calls a pre-buildworld mode mergemaster which compares the installed /etc/group and /etc/master.passwd with the new defaults so that you can choose what to adjust as needed, and then the install command.
Mergemaster deprecated, replaced by etcupdate.
Function of etcupdate is essentially the same, pre-buildworld option remains -p for this step.
mergemaster -p
etcupdate -p
make installworld
Should you see the message below, which can appear,
At installworld Make: "/usr/src/Makefile" line 360: Check your date/time
it is a simple fix, type the following command to continue:
adjkerntz -i
Now that the error is corrected, finish the command that was interrupted:
make installworld
The next steps will help update configuration files, allow you to merge your customized lines with the new file as needed, while automatically handling those files which are essentially identical or have not been user-modified.
mergemaster -iUF
etcupdate -n
-n Enable “dry-run” mode. Do not merge any changes to the
destination directory. Instead, report what actions would
be taken during a merge
etcupdate
It is good practice to be certain old libraries and other assorted files are not left around to cause problems, especially true between updates of major versions, so the next two commands will help remove all of them automatically. The command below, yes repeats 'y' to fulfill prompts, thus agreeing to each deletion which automates the script. Yes as described by its manpage can be used to repeat any text.
yes|make delete-old
yes|make delete-old-libs
Now that everything is finished, you can reboot one last time to load up and use your newly updated system. If for any reason there is a failure with booting, refer to now I can't boot for some steps to help solve it.
