So OpenBSD 5.8 was released. This will be my first real OpenBSD update. My firewall runs OpenBSD. I started on 5.6, but that was when I was playing around with FreeBSD and OpenBSD on a USB thumb drive while running Debian Linux as my main firewall. So when I did my first real install of OpenBSD on that actual Hard Drive it was 5.6, but 5.7 came out shortly after that. Since I hadn't really customized much, except my pf.conf and a few minor things, like dhcp, I just backed those up and wiped it out and re-installed. I really wanted to re-do the partitions a bit anyways (volume management is still one of the biggest things I miss in OpenBSD).
So with 5.8 I actually wanted to do a real upgrade. So first I went and got 5.8, I downloaded it from a mirror close to me, as I'm sure all of the OpenBSD sites were busy. OpenBSD has a page dedicated to each upgrade (5.6 to 5.7, 5.7 to 5.8, etc). I recommend looking at the page that applies to your upgrade. It will include specific files to delete that you no longer need, as well as other important notes that specifically apply to this upgrade. Since I was able to access my console directly I did their recommended method. I took the media, put it into the computer, booted from it. At that stage I selected U for upgrade. It asks similar questions to the installation, only not as many. At the end of that, it runs sysmerge and shows you diffs of your configuration files and the new configuration files (when needed). Mine only had two configuration files come up, and it was only one or two lines in each that needed to be adjusted. The only thing I did after that was update my package path (PKG_PATH) environment variable to 5.8 from 5.7 and then run:
pkg_add -u
That's pretty much it to an OpenBSD update. Very simple and very quick.
Since the source is pretty much locked in before the release date some erratas come out and are ready to applied on day one. For 5.7 I did these by using the src.tar.gz and sys.tar.gz and extracted them into /usr/src. Then I would go to the errata page and down load the patches as needed, and run the recommended steps. This worked perfectly for me. With 5.8 however, and it may be related to errata 6, I just couldn't get a version of the source code where SSH would re-compile. That was the first errata. And when I ran errata 7, it some how corrupted libc. Nothing ran. I'm not exactly sure what happened. I actually re-ran the update to get my system back working. That works great by the way because it basically extras all the files again.
So what I ended up doing to patch, was basically going to the OpenBSD anoncvs page and following their stable code base. It says it can take about 48 hours to get the latest errata patch. You can use cvs and download the code and then run the commands out of the errata, but since I had never build OpenBSD from source before, I thought why not try to compile everything. So first I made the kernel, and installed it. Then you reboot onto the new kernel.
Once you have the kernel compiled and running, you need to build all your userland/world/binaries/pick a word you like. I basically followed all the instructions on the OpenBSD site for this. It took over an hour, it could take longer if your machine is slower. Then I rebooted one more time just for good measure. And I am now running a fully patched 5.8 without issue.
I know some people stress out about the quick releases and basically only supporting 2 versions at any given time (the current and the previous releases, not to be confused with development CURRENT). But honestly I find the system quite nice. It lets you stay up to date, it eliminates a lot of unneeded stuff, and it's pretty easy to do. It also doesn't hurt that OpenBSD defaults are really good and you wont need to change a ton of settings. I think it also keeps the developers more focused. Some other operating systems or in the case of Linux distributions, have to worry about maintaining several versions and the developers have to multiple source trees. For a good example take Redhat Enterprise Linux, it currently has RHEL 3 just ending extended support last year (2014), RHEL4 still supported under extended support until 2017, RHEL5 with normal support until 2017, and extended support until 2020, RHEL6 with normal support until 2020-21 and RHEL 7 with normal support until 2024. I mention extended support because if a big company or government is using Redhat they may purchase this, and use that time to migrate a critical system to another release. Redhat usually recommends a clean install as their supported option, so many of these larger companies will do a fresh base install and migrate their application over to maintain their support contracts. I know, I've done several of them. That's not to say there aren't upgrade methods. So in any case when a big bug hits and gets a fancy buzzword name, and every news station covers it, non-technical people who are in management positions get freaked out and want every one to patch right away. Again I've done this several times too (patched the systems that is, not freaking out). So companies like Redhat, have to provide those patches, even to extended support. They can't just fix the code once and then compile it for all the different versions. The key point to the enterprise level operating systems is that they don't change major versions, only minor ones throughout the whole release. This is so your code/custom application never breaks from a new feature added, changed or removed. So the company may have to patch 4 or more different versions for that bug (if it applies to all of them). That also leads to other issues of your management wanting you to patch something that only applies to a newer or older version than what you have. It can be difficult to explain to them that it does not effect your setup when they said on the news virtually every one is effected.
But anyways, I see benefits and arguments for both methods. There are times when I would prefer either to be honest.