I always find myself having to dig out the following commands after I've upgraded my systems. Here's my contribution to working smarter, not harder.

Ports

• Unpack ports.tgz in the /usr directory.

• The following command will update the ports tree using anonymous cvs:

  # cvs -q -d anoncvs@anoncvs3.usa.openbsd.org:/cvs up -r \
  OPENBSD_4_4 -Pd
  

  For a list of anoncvs servers look here.

• To find where a package lives in the ports tree, use the following command:

  # make search key=programName
  

  Beats visual grepping all the port directories.

• To show available package flavors:

  # make show=FLAVORS
  

  To build a flavor:

  # env FLAVOR="flavorName" make install
  

Base System Source Code

• Unpack src.tgz and sys.tgz in the /usr/src. Do NOT unpack these archives in the /usr directory unless you want trouble.

• Apply patches from the top of the source tree - /usr/src using the following command:

  # patch -p0 < pathToPatch/001_patchname
  

  The instructions are fairly clear with regards what needs to happen after application of the patch. Don't skip any steps or bad shit will happen.

• Rebuild the kernel using the following commands:

  # cd /usr/src/sys/arch/i386/conf && config GENERIC && \
  cd ../compile/GENERIC && make depend bsd && mv /bsd /bsd.old && \
  cp bsd /
  

  I usually put this into an executable script in the /usr/src directory so that I can easily rebuild the kernel. You might want to install screen from ports before attempting to run this command on a Soekris 4801 or have the patience of a saint. If you've applied of patches in succession, you can issue a single rebuild instead of rebuilding per patch. That's just masochistic.

Not a very sexy title, but entirely to the point. It's been a while since I installed on my trusty Soekris 4801 and time has been both kind and capricious by dulling my memory regarding the arcana required to make this combo work. To save myself future frustration, I've decided to document the steps and commit them to the collective unconscious.

Just a little background; I began this project when I retired my rather thirsty and ancient Pentium Pro that served as my personal firewall/gateway for my home LAN a couple of years ago. I wanted a device that would not compromise on security and flexibility (hence the requirement to support OpenBSD) but also consume a reasonable amount of power. Enter the Soekris 4801 - an AMD Geode based embedded system. Base power consumption is 5W - 12W at peek. Not a powerful machine by modern standards, but certainly more powerful than my old system and more than sufficient for my needs. This system was cutting edge in the embedded systems space when I got it, but has been superceded by the newer 5501-60. For the record, the 4801-60 has the following specifications:

• 233 Mhz i386 compatible AMD Geode CPU
• 128 Mbyte SDRAM (embedded)
• 3 SIS 10/100BaseT Ethernet ports (embeded)
• 2 RS232 Serial extensions with a single 9 pin port
• 1 32-bit Compact Flash socket
• 1 44 pin IDE 66 connector
• 1 Mini-PCI socket
• 1 3.3V PCI connector
• 1 1621 dual port SIS 10/100BaseT Ethernet card attached to the PCI connector

Soekris Engineering also manufactures an add-in mini-PCI VPN accelerator (vpn1411), but I haven't gotten around to installing one of these yet. Although, the Soekris is ideally suited for flash based firewall distros, I opted to have a full version of OpenBSD. Storage for the OS is provided through a CF adapter which houses a 6GB Hitachi Microdrive.

Like most embedded systems, there is no built-in support for external peripherals, such as keyboards, mice, and video. All communications happens through one of the two serial ports. Thankfully, the engineers at Soekris were kind enough to wire up a port, otherwise you'd be left to your own devices to rig one up for yourself. The 4801 supports comBIOS, meaning you can use a null serial cable and a communications program (such as minicom) to manage the device through its entire boot cycle. This brings us to my first tidbit; communication parameters. The 4801 supports the following :

19200 8N1
hardware and software flowcontrol off 

Be sure that your communication software is configured with these parameters - their importance will become apparent when we attempt to update the 4801 with the latest BIOS firmware. It is good practice to use the latest vendor supplied firmware to reduce the possibility of potential hardware conflicts. However, without the correct parameters, attempting to update the firmware using the built-in BIOS monitor is impossible and will result in spurious cryptic errors being thrown. There were sites which suggested that the following xmodem parameters be changed to enable communications compatibility with the 4801:

/usr/sbin/sx -vv -b -X

but from my experience, disabling hardware flow control was sufficient to ensure seemless serial communications.

The process for updating the firmware is as follows and assumes that you are already connected to the 4801 through a serial cable :

1. Download the latest firmware from Soekris.
2. Reboot the 4801. At the boot prompt, interrupt the boot process using CTRL-P. This will bring up the boot monitor.

3. The official documentation refers to the download command to initiate file transfer. There is an undocumented option to this command however which will correctly initialize the file transfer session.

   download -

   Failing to provide the additional - argument will result in NAK errors when attempting to establish the communications channel.

4. Once the file has been uploaded, issue the following command:

   flashupdate

5. Reboot.

For more detailed instructions, please see the Updating the Soekris BIOS.

As there is no direct way to supply install media directly to the 4801, updating the 4801 requires configuration for PXE booting. At this point, I'd like to point out my second major caveat regarding the upgrade process:

The Soekris 4801 does not support PXE booting on any other interface other than the first ethernet port (ETH1).

I wasted a precious amount of time learning this lesson. Heed it well. This limitation also implies that to upgrade the 4801 requires it being in a network environment where the primary network interface can be configured. If this is not the case (such as when the 4801 resides on the network boundary), you will have to move it. Kiss goodbye to an in-place upgrade.

There are two services that are required to facilitate PXE booting - tftp and dhcp. The DHCP server has to be configured to supply an optional filename to a lease request made from the 4801's primary network interface. This implies that you know the MAC address of this interface. If you do not already have it, you can get it by forcing the 4801 into booting off the network using the BIOS monitor. See below.

The following is an example of a dhcpd.conf file that supports PXE booting

# dhcpd.conf
#
# Configuration file for ISC dhcpd (see 'man dhcpd.conf')
#

## GLOBAL OPTIONS
ddns-update-style ad-hoc;
default-lease-time 1200;
max-lease-time 9600;

subnet 10.0.1.0 netmask 255.255.255.0 
	{
		range 10.0.1.101 10.0.1.200;
		option broadcast-address 10.0.1.255;
		option routers 10.0.1.1;
		option domain-name "domain.com";
	}

host soekris
	{
		hardware ethernet 00:00:24:c3:90:f8;
		fixed-address 10.0.1.100;
		filename "pxeboot";
		option host-name "soekris";
		next-server 10.0.1.10;
	}

Please note the following :

• The argument to filename is not an absolute path. It is simply the name of the pxeboot file.
• The next-server option is required.
• The ddns-update-style global option is required for newer versions of dhcpd.

Following these guidelines when configuring dhcpd will save you from needless troubleshooting.

TFTP is usually managed through inetd/xinetd. Unfortunately, this results in arp network issues. It is recommended that tftpd run in standalone mode to avoid these issues.

The last part of the tftpd configuration requires creating a directory to serve out the pxeboot and bsd.rd files. Keep in mind that by default, tftpd runs as an unprivileged user (such as nobody). Ensure that wherever you place these PXE files, they have appropriate permissions for the daemon to access. Because we are using the console to manage the boot process, this PXE installation also requires an etc directory with a boot.conf file to configure the installer to use the console. The contents of the file are as follows:

stty com0 19200
set tty com0
boot bsd.rd

The order of these configuration parameters is important. The stty must come before the set command.

Believe it or not, at this point, you are ready to install OpenBSD. To get the 4801 to boot over the network requires the following steps:

1. Reboot. Interrupt the boot process using CTRL-P to enter the BIOS monitor.

2. Issue the following boot command:

   boot f0
   

I won't belabor the install details; you can get these directly from the main OpenBSD site. There is however one last caveat in this upgrade process: when the installer has completed unpacking the file sets, you are asked whether you want to set the current serial console as the default terminal. Say Yes! If you don't, when the 4801 reboots, it will hang attempting to load the kernel. This unfortunately leads to the boot process simply hanging at the following message:

entry point at 0x200120

Took me a while to figure this out. Hopefully others will not have to suffer quite as much as I did. Thankfully, OpenBSD has finally "modernized" and supplied a cleaner upgrade path than in previous releases. Hurray!!! About fucking time.

Will machines think like human beings, or will human beings begin thinking like machines?

This is an interesting question with rather practical implications to a programmer. Although there are certain advantages understanding the low level mechanics of how computers work, I don't think the relationship between that kind of technical knowledge and being able to write a program are necessarily related. No doubt a relationship exists, but I don't think it follows that knowing one automatically leads to the other.

Perhaps an analogy would better explain what I'm getting at. Technical details are like the study of linguistics compared to programs which are like prose/poetry. Knowing linguistics allows you to describe languages and their components such as verbs, nouns, adverbs, the rules of grammatical correctness, etc. This knowledge however doesn't mean that familiarity with these structural elements will automatically allow you to write meaningfully or expressively. These elements provide the constraints of expression when attempting to articulate an idea, but the articulation of the idea lies outside the bounds of this domain of knowledge. This is the same in programming. Although understanding how a computer functions or a compiler works is useful, it does not follow that you can write useful or meaningful programs just as knowing linguistics won't necessarily let you write literature. So what exactly is the nature of the relationship?

At its core, I think that the relationship can be summed up as follows:

Programming, as an endeavor, is still an exercise in expression.

How you choose to express an idea is as important as the idea itself. Like great literature which is firmly rooted in the language chosen by the author, a program acquires this quality of expressiveness based on the language which forms the foundation of a program. Although great writers sometime "break the rules" when writing literature, it is no different than the clever hacks exploited by programmers to express the difference between constraint and convention.

This idea of language as a source the expression implies that certain languages are better suited to expressing different ideas. No one single language is capable of the full range of expression because, at the point of its creation, the range of future expression is completely unknown. It also follows that languages evolve to fill that gap in expression.

So what is it that programmers seek in languages that they choose to solve problems? Quite simply, languages with real longevity possess an expressive quality that is both aesthetic and technical. Although semantics may vary widely between languages, this "expressiveness" is what programmers implicitly recognize and use to build their conceptual framework on which to hang those semantics. For lack of a better word (and borrowing shamelessly from Neal Stephanson and his novel Snowcrash), this is the Ur quality that is the root of all programming languages.

This brings us back to the question at the beginning of this article. Implicitly, expression is still a very human endeavour. Until this changes, I'm inclined to believe that machines will evolve to express very human ideas which will be reflected in the language we choose to express our intentions to them.

I think in this regard, Ruby is a step in the right direction.

Addendum

I found this article a day after writing this tidbit. Interesting how much the aesthetic guides intuition to the truth.