FreeBSD/i386 stable/8 on Dell OptiPlex GX260

If you happen to run FreeBSD/i386 stable/8 on older Dell desktop PCs, like an OptiPlex GX260, you might want to back out r262226 prior to upgrading to the latest revision. The change done to sys/dev/pci/pci.c in r262226 renders the kernel unable to mount the root filesystem.

You’re in the clear if you run 8.4-RELEASE, or stable/9, or stable/10 for this particular hardware. Maybe it’s time to move on to stable/10 or stable/9.

Luckily, none of my PowerEdge servers running stable/8 are affected.

Here’s what you should do (once) prior to running make buildworld buildkernel on affected systems:

cd /usr/src
svn up
svn diff -r 262226:262225 sys/dev/pci/pci.c | patch

The above action will add the character M to your kernel’s global revision number, indicating one or more local changes.

Should sys/dev/pci/pci.c be corrected for this deficiency in the future, you might want to revert the changes made above by running:

cd /usr/src
svn revert sys/dev/pci/pci.c
svn up

Youngest and oldest source file in FreeBSD base/head

While compiling a custom kernel for FreeBSD/amd64 base/head r264077, I began wondering how old is the oldest source file, how young is the youngest?

This is the command I devised:

ident /usr/obj/usr/src/sys/VBOX/kernel | grep FreeBSD | awk '{print $4,$5,$3,$2}' | sort -nr

The oldest source files are:

2003-06-10 21:44:29Z 116174 head/sys/crypto/sha1.c
2003-06-10 21:44:29Z 116174 head/sys/crypto/blowfish/bf_skey.c
2003-06-10 21:44:29Z 116174 head/sys/crypto/blowfish/bf_enc.c

The youngest source file is:

2014-04-03 01:46:03Z 264063 head/sys/netinet/tcp_input.c

That’s a span of about 10.815 years. Continue reading


I’m probably not paying enough attention to new developments in FreeBSD after all. After updating the installed ports in my VMs running base/head and base/stable/10, X11 stopped working. It turns out the new version of requires KMS and what not in the kernel. This doesn’t fare well with VMs running inside VirtualBox.

The solution? Place


in the /etc/make.conf file and recompile everything, or at least recompile everything belonging to the subsystem. I opted for the former, spending roughly five hours recompiling 443 ports. :-/

The VMs running base/stable/8 and base/stable/9 hasn’t been affected yet, but I figured it’s best to play safe and I amended the aforementioned line in the /etc/make.conf file on those VMs.

Your own virtualized desktop FreeBSD lab

If you’re like me, eager to test new stuff in FreeBSD, you might as well run a virtualized FreeBSD laboratory on your desktop. I use Oracle VirtualBox, but you might as well use Microsoft Hyper-V, real hardware, or some other contraption. Couple this with ZFS and boot environments, and you’re even able to rapidly revert any mishaps, although enabled ZFS features can’t be reverted without some help in advance from the virtualization software. Continue reading

UTF-8 in GNU Emacs

I nicked the following from

(setq locale-coding-system 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-8)
(prefer-coding-system 'utf-8)

You may also specify your preference toward the Unix newline convention:

(setq locale-coding-system 'utf-8-unix)
(set-terminal-coding-system 'utf-8-unix)
(set-keyboard-coding-system 'utf-8-unix)
(set-selection-coding-system 'utf-8-unix)
(prefer-coding-system 'utf-8-unix)

Yet another technical oriented blog, more or less