All FreeBSD systems under my care got upgraded last Friday to fix some NTP bugs. That upgrade introduced a new bug in the kernel. The bug first appeared at r298004 in
base/head, and later at r298134 in
base/stable/10. The i386-based systems were more notably affected than the amd64-based systems, as the former typically has less memory than the latter. Continue reading Memory leaks in recent stable/10 kernel
I spent some days last week converting our 32-bit AMANDA server to a 64-bit counterpart using spare but aged hardware. The former AMANDA server ran on very aged hardware in comparison. Going 64-bit also ment turning to ZFS-based storage.
Today, I replaced the two 320 GB first generation SATA drives with two 1 TB third generation SATA drives. The new drives, like their predecessors, are connected to the second generation SATA controller on the motherboard. Replacing the drives is nevertheless an improvement. Continue reading Replacing drives on AMANDA server
As of r294999 it’s possible to boot FreeBSD/amd64 stable/10 from ZFS pools on systems running UEFI firmware. Up until now I have booted my UEFI ZFS laptop using the older
boot1.efi boot loader with
/boot located on a UFS partition. Earlier today I updated my EFI System Partition (ESP), put
/boot back where it belongs, in the ZFS pool, and scrapped the UFS partition. Thanks to everyone who made this happen.
One of the old webservers at work, a Dell PowerEdge R200, crashed a couple of weeks ago. I suspect the six year old motherboard finally gave up. Continue reading Dell PowerEdge R320, JBOD, mfi(4), and gpart(8)
When upgrading from one major version of FreeBSD to another, in my case from FreeBSD/amd64 stable/9 to FreeBSD/amd64 stable/10, it’s customary to upgrade the installed ports afterwards, beginning with
I forcefully upgraded all installed ports using
portupgrade -afpv, but the upgrade of
lang/ruby21 failed miserably.
I removed all traces of Ruby 2.1, i.e.
databases/ruby-bdb, before manually compiling and installing
ports-mgmt/portupgrade using the ports collection.
Now, I needed to know which remaining ports were still compiled for stable/9. The following snippet allowed me to gather the origins of such ports:
pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1
Now, I could feed that list to the newly installed
portupgrade and upgrade the remaining ports:
portupgrade -fprv `pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1`
In the end, I should have removed
lang/ruby21 completely after upgrading
ports-mgmt/pkg, and reinstalled
ports-mgmt/portupgrade manually using the ports collection. Only then is it safe to forcefully rebuild and reinstall all the other ports. Don’t forget to add
devel/cvs if you used to rely on
cvs in base, and adjust all references from
Over the last few days have I experimented with UEFI and GPT in VirtualBox 4.3.26. The goal was to multiboot various operating system, in this case Windows 10 Enterprise Technical Preview 9926 x64 and FreeBSD/amd64 stable/10.
First, I thought of persuading the UEFI firmware to always present its boot menu. It sure beats remembering to press F12 each time I want to boot a different operating system. This proved impossible for a number of reasons.
Next, I came across The rEFInd Boot Manager. After a quick glance I saw this is exactly what I want, a UEFI boot manager. Continue reading UEFI, GPT, Windows 10, FreeBSD 10, and rEFInd
VirtualBox 4.3.24 is out, so I wanted to try out the UEFI version of the latest FreeBSD/amd64 stable/10 snapshot. It didn’t go well until I realised something important, however strange it may be. Continue reading UEFI booting FreeBSD/amd64 stable/10 in VirtualBox 4.3.24
I had a FreeBSD setup I wanted to replicate to another, identical computer. The source system runs ZFS and so should the receiving system. A recursive snapshot in combination with the
zfs send and
zfs receive commands proved most fruitful. Continue reading Replicating an entire FreeBSD system using ZFS
I have (successfully) attempted to migrate a running i386 stable/9 system into a running amd64 stable/9 system, and attempted to migrate a running i386 stable/10 system into a running amd64 stable/10 system, only to see if these tasks are in fact feasible. The results speaks for themselves, given the boundary conditions outlined below.
If your system has a separate root filesystem of less than 1 GiB, then I suggest you consider scrapping the 32-bit system altogether, and install a fresh 64-bit system. If you wish to continue having a separate root filesystem, make that filesystem no smaller than 2 GiB to accommodate future expansion. You may gain additional free space by deleting
/boot/kernel*/*.symbols prior to installing a new kernel. If this isn’t good enough, then you should limit the modules installed using the
MODULES_OVERRIDE directive in your kernel configuration file. (When 11.0 comes out, all kernel symbol files will live in
/usr/lib/debug/boot/kernel, relieving the stress on the root filesystem.)
The boundary conditions are:
- base built from the appropriate stable branch of the source code tree,
- amd64 snapshot for the appropriate stable branch to speed up parts of the transition,
- the system being able to run with the
GENERIC kernel until a new custom kernel is optionally installed,
- if your system needs a custom kernel to function properly, one can be precompiled on a spare 64-bit system and transferred to the subject at the right moment,
- ports built from the ports collection with
ports-mgmt/portmaster as a vital instrument, and
- the ports listed below.
Continue reading Migrating FreeBSD from i386 to amd64
While pondering why darkstat all of a sudden shows corrupted timestamps when running on FreeBSD/amd64 stable/9, I wrote a small program to decode the export format. The program is available using
svn co svn://svn.ximalas.info/darkstattype
or http://svnweb.ximalas.info/darkstattype/. The license is the 2-clause BSD license. Continue reading Decoding darkstat’s export format