OpenBSD Journal

New Upgrade Guide

Contributed by grey on from the improved documentation for the new release dept.

Nick Holland writes:

As any long-time OpenBSD user will know, the upgrade-minifaq.html page leaves you to do some figuring out of exactly WHAT needs to be done in /etc after an upgrade. People have also noted the upgrade-minifaq.html also ends up being a confusing mix of "all things to all people" -- a "how to upgrade by source" and "how to upgrade /etc, regardless of how you upgrade", covering both releases and -current.

With the release of 3.6, I have attempted to improve this a bit:
http://www.openbsd.org/faq/upgrade36.html

This document is intended to help people upgrade from 3.5-release to 3.6-release via binary files. It does NOT replace upgrade-minifaq.html (though upgrade-minifaq.html will probably be undergoing some serious revision, too), which will now be used mostly for people living on the -current edge. Upgrading from release to release by source is not recommended or supported, it's just too much work for no good reason.

This project was mostly the idea of Henning Brauer, who worked hard to get me to understand his vision (and Hennglish 8-). Yes, there are probably going to be additions and revisions to what is here now, but we hope to keep this a simple and clear document.

(Comments are closed)

Comments

  1. By Anonymous Coward (208.246.35.44) on

    So why is there not yet an upgrade script ? Seems like this is a major pain point for users and would certainly prompt faster upgrades to the latest version.

    Comments

    1. By Anonymous Coward (209.242.5.52) on

      mergemaster could probably be imported to make merging updates much easier, but we lack a gdiff in our tree.

    2. By djm@ (203.217.30.86) on

      Because you haven't written one! slacker

    3. By I.S. (212.184.216.33) on

      yes, this is a good question! maybe this great doc is only the first step to furthermore upgrade innovation's ... i hope so. :-)

      --ingolf

  2. By bob (80.138.138.45) on

    i have used the update36.html its, an i must say its a faster way as the update-mini-faq for the folks are updating with the bins via cdrom or ftp.

    thnx Nick and Hanning!

    best bob

    Comments

    1. By bob (80.138.138.45) on

      typo ..... Henning not Hanning :(

  3. By Anonymous Coward (67.71.18.168) on

    I really wish there was an easier way of handling third party packages during each new OpenBSD release upgrade. Manually removing all of them and then manually building each one with different flavors is a bit of a hassle.

    Comments

    1. By jkm (213.214.214.2) on

      Yep... I plan to write a script that makes it somewhat automatic to get the right pkgs from ftp and rem old/add new. Just need some time...

  4. By sickness (195.43.187.17) sickness@tiscali.it on http://www.sickness.it

    Just updated my laptop and my yosemite (and ordered cds :)
    Good work! Very useful!!!
    TNX!

  5. By JOS (84.27.70.72) OpenJOS@groomlake.org on

    From the guide:

    Install new userland applications 
    cd /
tar xzpf /path/base36.tgz
tar xzpf /path/comp36.tgz
tar xzpf /path/man36.tgz
tar xzpf /path/misc36.tgz
tar xzpf /path/xbase36.tgz
tar xzpf /path/xfont36.tgz
tar xzpf /path/xserv36.tgz
tar xzpf /path/xshare36.tgz

    This can go terribly wrong... For example when OpenBSD changed binary format, nothing would work after the first command (unpacking the base) completed. Not even the tar command itself, Leaving you with a corrupt system.

    You probably need to copy everything you need for the upgrade to a safe location, and execute from there.

    Comments

    1. By SeppoE (217.93.97.68) on

      "This document is intended to help people upgrade from 3.5-release to 3.6-release via binary files." As I remember the change in binary format was in 3.4 -> 3.5 or even earlier. Another good way there to raise hell was having the root-login-shell set to /usr/local/bin/bash during upgrade =8(

      Comments

      1. By JOS (84.27.70.72) on

        The guide is for 3.5 to 3.6, but my point is: you should not depend on the environment you are upgrading to be stable during the upgrade. You should "bring along" the tools you need, just in case something breaks during the upgrade. The binary format change was just an (real-life, unfortunately) example.

      2. By Anonymous Coward (193.63.217.208) on

        That would be why I install statically linked shells, copy them to /bin and have a second root user with the more convenient shell...

    2. By Nick Holland (68.43.115.33) nick@holland-consulting.net on http://www.openbsd.org/faq/upgrade36.html

      you missed the steps RIGHT BEFORE THAT...
      1) install new kernel
      2) reboot off new kernel.

      The new kernel has to be able to run the old binaries for this to work, of course, but in the case of 3.5->3.6, which is the ONLY upgrade this document covers, this is the case on all platforms. In fact, if you DON'T do that first, you will encounter the problem you describe, which is also mentioned in this document. There's a reason those steps are in there. :)

      You also will note that this is NOT the recommended process.

      When OpenBSD 3.7 comes out, there will be a upgrade37.html document. I hope to have an upgrade35.html document (covering 3.4->3.5) going in moderately soon.

      Use the wrong instructions for an upgrade, you will get hurt.

      Comments

      1. By Anonymous Coward (134.100.120.75) on

        I hope to have an upgrade35.html document (covering 3.4->3.5) going in moderately soon.
        Thank you ! Thank you ! Thank you ! That will be very useful for those still running 3.4 and needing to upgrade (like me). Especially the part about dumping kernel and distribution sets into / on something like remote machines (like me).

      2. By JOS (212.187.118.188) on

        <smart*ss_mode>Actually, if you followed those instructions when the binary format upgrade took place, your system wouldn't boot at all after copying the new kernel in place. You have to install a new bootloader as well.</smart*ass_mode>

        As I said, this was only an example of why I think you should have a copy of all tools needed during the upgrade. Dependancies can bite you when you least expect it.

        Not tying to critisize the work you did, just trying to point out an unusual situation I encountered so others don't get the same problem. The doc is great, and imho good documentation is as important as good documentation.

  6. By Alan Post (207.66.36.189) aisa@predict.com on

    Reading the upgrade mini-faq, I am confused by conflicting advice in section 3.5.10 (Library bump flag day) and 3.5.1 (pty device minor numbers changed). It is clear that the author was tracking current between these two pieces of advice.

    In 3.5.10, It is advised to install a new kernel before installing all of the libs, but in 3.5.1 it is advised to build userland before rebooting to the new kernel.

    My guess would be that the library bump will work fine on a 3.5 kernel, and that booting a 3.6 kernel before the userland was compiled to use the new pty devices would not work. Does anyone have experience doing this?

    Comments

    1. By henning (213.128.133.133) on

      > Reading the upgrade mini-faq, I am confused by conflicting advice in
      > section 3.5.10 (Library bump flag day) and 3.5.1 (pty device minor
      > numbers changed). It is clear that the author was tracking current
      > between these two pieces of advice.

      the upgrade-minifaq is a horrible mess between tracking -current, release upgrades and general information for building from source.

      the steps listed there from release to -current are indeed only for thise tracking -current. It is actually the place for our developers to quickly check how to get their machines up to -current - we're just beeing nice and make that public.

      that said, the upgradeXX.html document is a very very important step to kill the upgrade minifaq, but just a first one. "tracking -current" should take over its most important remaining role, and the general building info can go elsewhere.

      to come back to your original question - going from 3.5 to 3.6 by src and some steps are conflicting - who cares. it is completely irrelevant. there was enough time between those two steps in -current, and goinf from one release to another is just dumb. actually, it is worse than just dumb. it is in the "doctor, doctor, when I put my finger in my eye it hurts" category, and the answer is the same - don't do it, then.

      once again I want to add what a fantastic document nick made out of my rather vague and probably extremely chaotic ideas. incredible!

  7. By Anonymous Coward (157.246.2.6) on

    This guide is perfect and needed, Nick. Thanks for your work.

  8. By george (212.70.193.155) on

    mergemaster (installed from ports) can be used to upgrade /etc with less hassle. I am surprised that it is not mentioned anywhere.

    Comments

    1. By Anonymous Coward (68.125.29.100) on

      An upgrade ought not depend on third party tools.

      Comments

      1. By Kevin R (198.53.249.58) on

        But it (openbsd) doesn't "depend" on third party tools. You can upgrade without them. Their optional, to help with an upgrade if you want/need them.

      2. By george (212.70.193.155) on

        Of course I agree with you, but if it helps why not use it? Being a purist is a demand when you are the release engineer for the OS (meaning that Theo *must* be a purist). OTOH, when you have 10+ OBSD servers to upgrade, mergemaster is a real help.

  9. By RC (4.8.23.152) on

    I recently upgraded from 3.4 to 3.6 directly.

    The main problem I had was with X11. The keyboard files have obviously changed, so xkbcomp dies, and X11 starts up without the keyboard working at all.

    I didn't take the time to figure out whether the bins or the conf files were to blame. I just removed /etc/X11 and /etc/X11R6 and installed the new x*.tgz packages clean. In addition, I wanted to keep my old packages working for a while, so I re-installed the old xbase34.tgz package, which provides the X libs the old packages need.

    The only other problem I've had is that systrace scripts for the older packages needed to be changed slightly. For instance:

    "native-shmctl" is now "native-compat_35_shmctl35"

    There are a few others: shmget fstat35 stat35 lstat35


    Other than those bumps in the road, everything has worked flawlessly thus far.

  10. By Nick Holland (68.43.115.33) nick@holland-consulting.net on http://www.openbsd.org/faq/upgrade36.html

    Since this page was first published, a couple errors have been found. The first is relatively minor, the other could be more important to some people, I'd suggest fixing both.

    1) the login shell for the new users is "/sbin/nologin", not the "/bin/nologin" that I had there at first.

    2) The login name for the TFTP user is "_tftpd", not "_tftp".

    Both of these issues are fixed using "vipw(8)". The user numbers impacted by those errors are 77 through 83.

    I'm not aware of any situation where the first error would be significant, but fix it anyway. The second is more significant, but only to people running tftp...or people who MIGHT run it in the future. So, I HIGHLY encourage you to fix this one -- it might be some time down the road that you need to run tftpd, and figuring out why it doesn't work might be annoying long after this error is forgotten... Through more good luck than good management, all the errors are in the same area, and fixed using the same tool, so might as well get them all at once.

    My appologies to any inconvinience these caused...

    Nick.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]