After upgrading one of my Kodi media center boxes from a Raspberry Pi B+ to a Raspberry Pi 2, I decided to play with NetBSD on the old Pi B+. Installing NetBSD is a simple process and the install docs cover it well, but here are a few notes that might be useful for completing your post-install configuration. The NetBSD documentation should be your first resource, of course; this just covers a few Pi-specific things I found relevant.

Since the install process is really just writing a disk image to the MicroSD card and then booting the system, you’ll have to manually complete a number of configuration steps that would usually be handled by the installer. Fortunately, it’s pretty straightforward.

First Boot

Expect the first boot to take some time. The system will resize the / partition to use all available space on the MicroSD card (more on this later) and generate SSH host keys. This will not be fast.

You’ll eventually get a login prompt. root has a blank password by default. Hostname will be rpi. The DHCP client is active by default, so you may have a working network connection.

Network Configuration

I wanted a static IP address, so I created /etc/ifconfig.usmc0 with the contents:

inet netmask

I also defined my DNS nameserver in /etc/resolv.conf:


NetBSD uses the /etc/rc.conf file as the main system-wide configuration file. The following changes are all made to that file.

I defined my hostname and default route, and disabled the DHCP client:

Time Configuration

The Pi has no real-time clock, so you’ll want to use ntpdate to set the clock at boot. The -b option jumps the clock to the correct time, rather than trying to correct it by slewing. I also chose to enable ntpd to keep the clock synched:


The system will be using UTC time by default. Set it to your preferred timezone instead:

ln -fs /usr/share/zoneinfo/Your/Zone /etc/localtime

It’s not gonna get any bigger!

After the first boot, there’s no need to try to resize the disklabel and root partition on every reboot, so those options can be turned off:


Enabling PF

NetBSD includes a (rather outdated) version of OpenBSD’s excellent pf firewall, which I wanted to use. Note you’ll also need an appropriate pf.conf file. To enable pf and the pf logging daemon:


pkgsrc Configuration

NetBSD uses pkgsrc for package management. Somewhat confusingly, you don’t actually set your $PKG_PATH variable in /etc/pkgpath.conf; it goes in /etc/pkg_install.conf instead:


You can then pkg_add to your heart’s content. Note that pkgsrc does quarterly releases of binary packages, so the 7.0_2015Q3 portion may need to be updated.

More Power! More memory!

The Raspberry Pi doesn’t have anything like a BIOS interface for setting low-level hardware configuration options. Instead, you can edit the /boot/config.txt file to make changes. On my system, I’m doing a moderate overclock to extract a bit more performance from the anemic hardware. Obviously, do this at your own risk; my Pi has added heatsinks and has been perfectly stable with this mild overclock.

By default, 64 MB of memory will be allocated to the GPU. If you’re planning to run your Pi headless, there’s no reason to dedicate unneeded memory to graphics, so you can crank that down to 16 MB:


Unresolved Issues

As mentioned earlier, the first boot process will resize the / partition to use all available space on your MicroSD card. I’m not a huge fan of this, since I really like having at least /var and /tmp on their own partitions. A reasonable approach would seem to be: shrinking the filesystem on /dev/ld0a using resize_ffs, updating the disklabel to match, then adding new partitions and filesystems as desired.

I haven’t actually been able to accomplish this yet due to issues with resize_ffs. I’m using a 32 GB SD card with my Pi, which results in a / partition of 28 GB. If I boot single-user and try to shrink the root partition with resize_ffs, I get the error:

resize_ffs: Can’t map 1936261120 bytes for inodes: Cannot allocate memory

resize_ffs is trying to grab 2 GB of memory on a box with 512 MB total, which obviously isn’t going to fly. I’ll have to circle back to this. I think a better approach would be updating the disk image to NOT resize on first boot.

Version 14.0 of XBMC came out a few days before Christmas, though it’s now rebranded as Kodi (not a fan of the new name). I took advantage of some vacation time to rebuild my setup and update from XBMC 13.1.

Previously, my XBMC systems were Windows-based. Not my first choice, but back when I built them, there were major hassles involved with getting HDMI audio to work properly in Linux. Windows clients meant I needed Samba on my file server, which was also not my first choice.

For the rebuild, I chose OpenELEC, which is essentially a very stripped-down, appliance-like Linux distro that runs on multiple hardware platforms. Being Linux-based, it can speak native NFS, which allowed me to ditch Samba.

Server configuration

My OpenBSD file server uses MariaDB for the SQL back-end and the native NFS server for presenting the media library. NFS configuration on OpenBSD is simple and well-documented. Configure your exports in /etc/exports and enable the portmap,mountd, and nfsd daemons; that’s all there is to it.

Minor annoyance: portmap and nfsd bind to consistent ports, but mountd picks 2 random privileged ports. Annoying, but that’s how the protocol is supposed to work, per RFC 1094. If you use PF on the NFS server, you’ll need some ugly rules like:
pass in on $lan_if inet proto udp from <kodihosts> to $lan_if port < 1024
pass in on $lan_if inet proto tcp from <kodihosts> to $lan_if port < 1024
Or, if you want to be more thorough, dynamically update the ruleset via a script and anchor.

OpenELEC clients

OpenELEC installation is straightforward; just follow the docs. I replaced one of my old (and increasingly noisy) PCs with a Raspberry Pi. I mildly overclocked it and added an MPEG-2 license to get hardware-accelerated playback of DVDs.

OpenELEC works very well as installed, but one area needed some attention: by default, it allows ssh access to root, with a hardcoded, publicly-published password. No, seriously:

How do I change the SSH password?

At the moment it’s not possible to change the root password as it’s held in a read-only filesystem. However, for the really security conscious advanced user, you can change the password if you build OpenELEC from source.

This is utterly insane and indefensible. While you wouldn’t want to expose one of these systems to the Internet in the first place, this kind of total disregard for security is just appalling. And their suggested solution is to recompile everything with a different hardcoded password.

A much better solution is to set up ssh keys and then disable password logins, which can be done from within the GUI.

Library Sharing

Setting up Libary Sharing is well-documented and straightforward, assuming you have a bit of SQL familiarity. I’m not thrilled by their suggestion to GRANT ALL ON *.* TO 'xbmc';, but since nothing else is using that SQL instance, I won’t squawk too loudly about it.

Once the initial setup is done, additional clients just need the advancedsettings.xml file to connect to your database and find your library. Fairly slick.

The Inevitable Snag

Every IT project has one…

I installed the Kodi .apk on my Android tablet, added my advancedsettings.xml file, and promptly found that I couldn’t play any videos on the tablet. A few minutes of troubleshooting ran down the issue.

Kodi insists on using unprivileged ports for NFS:

Your NFS server on your NAS needs to be able to allow connections on so-called unprivileged ports, which are port numbers higher than 1023. However, most NAS’s are set up by default to deny incoming NFS connections on these unprivileged ports.

And OpenBSD’s mountd does not allow them:

The -n flag historically allowed clients to use non-reserved ports when
communicating with mountd. In OpenBSD, a reserved port is always used.

So… that simply won’t work. Fun.

SSL Certs… again

Huh, there’s still a blog here. Neat.

After all the fun I had with generating and installing an Android-compatible CA cert, the Android 4.4.2 update for my device decided to throw one more curve my way: a persistent notification that “Network may be monitored By an unknown third party,” thanks to my self-signed root cert.

Sigh. Spend enough time fucking around with self-signed certs and the $9/year for a “real” SSL cert quickly begins making sense. After all, those are trustworthy because no “real” CA has ever been compromised, right? Right?

… under a very loose definition of “fun.”

This one sent me down a rabbit hole for a few hours, so I figured I’d write it up for my own future reference, and maybe spare others from some pain.

I have an OwnCloud server with an SSL certificate signed by my own CA cert, and I was trying to set up DAVdroid to sync my calendar and contacts against it. First, I had to get my CA certificate installed on my phone, which goes something like this:

  1. Get the CA cert into DER format, with a .cer or .crt file extension. The magical OpenSSL command-line incantation will look something like: openssl x509 -outform der -in certificate.pem -out certificate.crt (no, I don’t know why Android can’t accept PEM format. Google says you need DER or PKCS#12.)
  2. Get the CA cert onto internal storage. Post it somewhere you can download it, or copy it to an SD card and then to internal storage. (No, I don’t know why you can’t load it directly from the SD card. Because Google, I guess.)
  3. Go to Settings > Personal > Security > Credential storage > Install from storage. Android should find the cert and prompt you to install it.

That all went well enough, and Android told me the cert was successfully installed. Weirdly, though, I didn’t actually see it listed under the user-installed CA list. It also wasn’t actually working. I browsed to my OwnCloud site and got a certificate error. DAVdroid also refused to connect to my OwnCloud server, reporting only “Cannot verify hostname.”

(insert 80s-style montage representing too much time spent researching and reading documentation)

Eventually it became clear that my CA cert was in X.509 v1 format, and Android insists upon X.509v3 format, with the basicConstraints=CA:true extension. This appears to be an Android-specific quirk; I’ve never had a problem importing my CA cert into a web browser.

Solving the problem required regenerating my CA cert with the required X.509v3 extension. That, in turn, required digging into the truly awful OpenSSL documentation to figure out how to accomplish such a seemingly simple task. In the end, I couldn’t find a way to specify the basicConstraints=CA:true extension on the command line; instead I added this stanza to my openssl.cnf file:


Then, I generated a new CA cert, adding -extensions x509v3_CA to the command-line arguments. Generated a new CSR, signed it with my new CA cert, juggled all the files to the right places, and imported the new CA cert into my phone. Sure enough, it imported successfully, showed up in the list of user-installed certs, and made the Android browser and DAVdroid happy.

It appears that there may be a way to add this extension to an existing CA cert to avoid regenerating everything, but (A) I was already far enough down the rabbit hole, thanks, and (B) I only needed the one certificate for my own personal use.

Google had a bug report opened for this issue, but closed it as “WorkingAsIntended”. If you say so, guys…

I’m told that the process for adding a CA cert to an iPhone is even more tortuous (torturous?), but I have no plans to go down that road.

I did not know that.

I was looking into a MySQL performance issue with one of my teammates when I ran into this odd little quirk.

Older versions of MySQL come with a set of sample configuration files (my-small.cnf, my-medium.cnf, my-large.cnf, and my-huge.cnf) suitable for systems with varying resources and workloads.

The my-large.cnf and my-huge.cnf files set a value for the thread_concurrency variable and suggest, “Try number of CPU’s*2 for thread_concurrency.” Since we were working on a 4-core system, setting a value of 8 seemed like a good idea.

Except, as it turns out, it’s basically worthless. thread_concurrency only works on old versions of Solaris and does nothing at all on other OSes. Which makes one wonder why it’s included in the sample configuration files…

OpenSSL and AES-NI

Playing around with OpenSSL’s built-in speed test today, I discovered that the default ‘openssl speed’ command won’t take advantage of AES-NI acceleration, even if your processor supports it. To get AES-NI goodness on the speed test, you have to specify the ‘-evp’ option along with the AES mode to speed-test.

On a Core i5 M 520, without using AES-NI:

OpenSSL 1.0.0f 4 Jan 2012
built on: date not available
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: information not available
The ‘numbers’ are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      38655.36k    42473.27k    47143.80k    98004.28k    98783.00k

and with AES-NI:

OpenSSL 1.0.0f 4 Jan 2012
built on: date not available
options:bn(64,64) rc4(8x,char) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: information not available
The ‘numbers’ are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     356674.40k   379020.78k   416202.59k   418317.61k   418009.73k

This is on an OpenBSD/amd64 5.2 system. Yes, it’s (over-)due for an OS upgrade. But yeah, AES-NI gives you a performance boost of 4x-9x. Nice!

XBMC on Nook HD

The Android port of XBMC seems to work pretty well. After installing the .apk and launching the app once so it could create its config files, I just had to add my advancedsettings.xml and passwords.xml files to get the tablet talking to my Samba/MySQL back-end.

It appears that hardware decoding might not be working; standard-definition content plays just fine, but 720p x264 video stutters badly, and 1080p is hopeless. It’s still early days for XBMC on Android, so this may (hopefully!) improve with the next release.

Sitting with a friend in the in-store coffee bar at a Barnes & Noble this afternoon, getting caffeinated to the gills, an announcement over the PA system caught my attention: Nook HDs (the little Android tablets that had just been discontinued a few days previous) on sale for $99. Hmm.

I’d avoided tablets until now for a couple of reasons: the chaotic and immature market, with dozens of companies seemingly introducting and discontinuing models on a daily basis, and my own lack of a clear need/use for a tablet.

Also, I’d never seriously considered the Nook (or Amazon’s competing Kindle tablets) because I’m really not interested in a specialized tablet designed to channel money directly from my wallet to an e-tailer, all while staying securely confined within their walled garden. But a few minutes of Googling revealed that an unoffical port of the Cyanogenmod open-source firmware existed and could be installed without undue hassle. Hmm again.

A quick review of the specs showed a dual-core processor, a gig of RAM, and a 7″ LED-backlit screen at a rather impressive 1440×900 resolution. For a C-note. And I get to have a little fun hacking it and subverting the manufacturer’s intended use. Alright. Sold.

I found a quick-and-dirty HOWTO on installing Cyanogenmod (downloading cryptically-named ZIP files from a Russian website! This can’t possibly end badly!) and had the OS up and running within a half-hour. Then I loaded the .apk for the F-Droid open-source software repository and had a shiny little 100% open-source tablet sitting on my kitchen table.

Initial impression is positive. It’s snappy and stable so far, though I can’t say I’ve really thrown much of a workload at it yet. Some of the features you’d expect in a general-purpose tablet are missing; notably, there’s no cameras or GPS. Will I miss either feature? Probably not.

It remains to be seen how much use I’ll get out of a tablet. I installed the FBReader e-book reader, along with VLC and a handful of other apps. There’s a not-entirely-polished Android port of XBMC that’s worth playing around with. Tablets are obviously better suited to media consumption than creation (I’m typing this on my laptop right now…) so we’ll start out with books, movies and music. Stay tuned?

I have a couple of Windows boxes I use as XBMC media center clients. Basically, they’re configured as appliances; I fire ’em up via Wake-on-LAN, they auto login and launch XBMC. Simple enough. The MySQL back-end and Samba shares live on an OpenBSD host on my LAN. I set up library sharing per the guide on XBMC’s wiki, and it worked. Mostly.

The “update library on startup” feature never worked at all, and I’d occasionally get a “File is no longer available” error when I tried to play a file. Running an “Update library” would get things working again. A minor irritation, and since I always ran into it just as I was getting ready to watch a movie, I never really felt like putting on my IT Guy hat and diving into a debugging session.

Cumulative annoyance finally got the better of me, so I turned on debug logging and saw a bunch of entries like:
WARNING: VIDEO::CVideoInfoScanner::Process directory 'smb://user:pass@' does not exist - skipping scan and clean.

Googling for “CVideoInfoScanner” led me to this thread on the XBMC forum, and this post had my solution:

Fixed the issue by going into saved credentials on my PC and adding the SMB password for the shared folder. Start -> run -> netplwiz -> advanced -> manage passwords -> windows credentials -> add a windows credential -> network address: \NAMEOFSHARE

Sure enough, that works. It’s odd, though. XBMC expects to handle SMB shares on its own, at the application level, rather than working on a mapped drive. And it stores the credentials for the shares in its own passwords.xml config file. So why does storing a credential in netplwiz fix this problem? Dunno. And I’m not really inclined to go any further down that rabbit hole today.