Twitter Email
silvercircle No addendum
A Jekyll test site with no particular purpose.

FreeBSD Cheat Sheet

Author: Alex Vie
Title: FreeBSD Cheat Sheet
Language: en-US
Categories: Development
Created: 03:02 on Wednesday, 09. May 2018
Modified: 02:02 on Wednesday, 09. May 2018

This is a personal collection of items I took note of for later reference, after I recently picked up FreeBSD again.

May not be useful at all for anyone except myself and is kept here for personal reference mainly.

Tags: firstfreebsd
Page layout: no_sidebar
Media: 2 Object(s)
Last modified:
1162 Words
03:02 | by Alex Vie in Development
Reading time: approx. 4 minute(s).
Fresh installed and a bit customized.
Fresh installed and a bit customized.
Fresh installed and a bit customized.

I recently came back to FreeBSD after many years (the last version I used was 6.1 a decade or so ago) and found a lot of things have changed, but it still feels very familiar and somewhat „home”, even after so many years. Kudos to the devs for keeping the traditional BSD-ish feeling alive and rocking. Installation (in a VMWare virtual machine to begin with) went smooth and everything felt like I had left it only recently. Except that it now has binary packages, similar to most Linux distributions, switched from GCC to clang1 and got the most impressive and powerful filesystem ever designed for an OS fully working as a first-class citizen.

This is a personal collection of items I took note of for later reference. It’s by no means complete and probably totally useless for anyone except myself.

Fetch source code archive for running version

Normally, the source code can be installed during system installation from the installation media and freebsd-update will keep it up-to-date with patches. Source installation is optional though and can be performed later. When doing so, it is important to fetch the source code that matches the current release. The following command will do this:

fetch -o ~`uname -s`/releases/`uname -m`/`uname -r | 
    cut -d'-' -f1,2`/src.txz

This will download a complete source archive and save it as src.tgz in your $HOME. Un-tar this to / to get a fully populated /usr/src.

Install papirus icons (there is no pkg or port yet)

Papirus is a popular and modern - looking icon theme for desktop environments. It works with GNOME, MATE, Xfce, KDE and others and contains an impressive number of icons for all kind of purposes. Papirus icons come in different color variations so its sub-themes can be used with either light or dark backgrounds. These icons looks particularly nice on flat and minimalistic themes, like Arc or Deepin.

wget -qO-
    | DESTDIR="/usr/local/share/icons" sh

Mount VMware share:

VMWare shared folders are supported via the fuse filesystem, particularly the vmhgfs-fuse utility, which is part of the open-vm-tools port/package. The old method via the vmhgfs kernel module (mount -t vmhgfs ...) is no longer supported.

   kldload fuse  (or fuse_load="YES" in /boot/loader.conf)
   /usr/local/bin/vmhgfs-fuse .host:/NET_DATA/mnt/darkstar -o allow_other
   Warning: the share (NET_DATA in this example) name is CASE SENSITIVE and must 
   match the name as defined in VMware

Upgrading strategy

Upgrading FreeBSD has become surprisingly easy. The exhaustive freebsd-update script will take care of most things, including minor (e.g. 11.1 -> 11.2) and major (e.g. 11.x -> 12.0) upgrades. It will also keep the security patch level (that’s the -pX part behind the version number) current within a given release.

The script does have some caveats when you need (or just want) to run a custom kernel. Normally, make installkernel installs a custom built kernel in /boot/kernel, which is the default location. The old kernel will be backed up to /boot/kernel.old.

In order to identify the patch level of the running system, freebsd-update needs a GENERIC kernel in /boot/kernel. This is the kernel that ships with binary releases and which can be built by doing a make buildkernel KERNCONF=GENERIC. It’s configuration is /usr/src/sys/<arch>/conf/GENERIC and should not be changed in any way. Don’t change GENERIC as it may confuse and complicate things. Leave it alone and build your own custom kernel with its own configuration.

I’ve found the following strategy works well enough with a custom kernel. It totally ignores the default directories in /boot so freebsd-update can do its work and will never ever see the custom kernel.

  • Leave the GENERIC kernel in /boot/kernel alone. The freebsd-update script easily gets confused with a custom kernel in default location(s)

  • If you really need a custom kernel, install it in /boot/MYKERNEL or any directory of your choice (e.g. /boot/kernel.$HOSTNAME) and tell the boot loader to load it as default kernel:

  • modify /boot/loader.conf:
     # kernel options
     kernels="kernel kernel.old kernel.NEXUS"
     # other options...
     vmxnet ="YES"
  • This instructs the loader to load kernel.NEXUS from /boot/kernel.NEXUS by default.
  • Make sure /boot/loader.rc contains the following 2 lines:
   include /boot/loader.4th

Otherwise, /boot/loader.conf will not be used.

   freebsd-update fetch
   freebsd-update install

The output of freebsd-update will tell you whether the kernel needs to be recompiled. If patches were applied to /usr/src/sys then you should rebuild your custom kernel.

Additionally, the daily 3:00am housekeeping cron job will check whether kernel and userland are in sync.

Install kernel to custom directory

   make buildkernel   KERNCONF=NEXUS INSTKERNNAME=kernel.NEXUS
   make installkernel KERNCONF=NEXUS INSTKERNNAME=kernel.NEXUS

Builds and installs a custom kernel to /boot/kernel.NEXUS - the INSTKERNNAME is an undocumented make option. This is preferable and simplifies updating. Just keep the GENERIC kernel in /boot/kernel and adjust /boot/loader.conf accordingly (see above) to boot the custom kernel from its own directory. If anything goes wrong, a GENERIC kernel will always be available as backup.

Check the identity of the running kernel

The following command can be used to check the IDENT string of the running kernel. This is the same string that appears in the kernel configuration file and is set to GENERIC by default. A custom kernel should have its own identity string to distinguish it from the generic kernel that ships with the OS.

    sysctl kern.conftxt | grep ident

Switch to latest package repository.

By default, stable releases use the quarterly repository within the package infrastructure. Quarterly can be seen as some kind of stable branch. It’s updated less frequently and does not always contain the latest version of a given software available. The latest branch is less conservative and will offer you more recent applications. One example: At the time of writing this (May 2018), KDE5 is still not in quarterly even though it has been in latest for months.

The configuration for the pkg utility can be found in /etc/pkg/FreeBSD.conf:

# $FreeBSD: releng/11.1/etc/pkg/FreeBSD.conf 320745 2017-07-06 17:22:33Z gjb $
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf

FreeBSD: {
  # url: "pkg+${ABI}/quarterly",
  url: "pkg+${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes

Simply change the first line of the FreeBSD block from quarterly to latest. To reflect the changes you must then do a sudo pkg update to re-load the repository. If you were on quarterly for a prolonged time, be prepared for a lot of package upgrades when you next do a sudo pkg upgrade.

  1. This is something you won’t even notice unless you know it. Clang behaves almost exactly like GCC, mimics its options and even most of the error messages.