OpenBSD Journal

Quick Upgrade Process

Contributed by dwc on from the 10-steps-to-a-more-current-you dept.

Mike Erdely wrote in his blog:

Not including the download of the installation sets, the whole [upgrade] process took less than 20 minutes and I was back in X. It took longer to write this post than to upgrade my laptop.

Mike describes his quick, painless upgrade to 4.2-current. While well documented elsewhere, he demonstrates how easy upgrades have become with the improved tools in OpenBSD 4.2. From the article:

I just finished upgrading my Thinkpad T42 to the latest OpenBSD 4.2-current snapshot and thought I should share my upgrade process. Over the past few releases of OpenBSD, the process has gotten steadily easier. Marc Espie has almost single handedly overhauled the ports system into a robust, easy to upgrade system. And I especially like the clear distinction between the system base and add-on packages.

Read the full article on his site.

(Comments are closed)

Comments

  1. By Anonymous Coward (85.178.112.42) on

    I wonder how the FFS->FFS2 migration was done....
    Doesn#t 4.2 include FFS2?

    Comments

    1. By Brynet (Brynet) on

      > I wonder how the FFS->FFS2 migration was done....
      > Doesn#t 4.2 include FFS2?

      I've seen some FFS2 related commits, but I think it's still not quite ready for being "default".

      I'm going to "guess" that the next few releases will stick with FFS, but who knows.. :-)

      Comments

      1. By Anonymous Coward (85.178.112.42) on

        > > I wonder how the FFS->FFS2 migration was done....
        > > Doesn#t 4.2 include FFS2?
        >
        > I've seen some FFS2 related commits, but I think it's still not quite ready for being "default".
        >
        > I'm going to "guess" that the next few releases will stick with FFS, but who knows.. :-)

        Seriously: That would suck badly... but hopefully FFS2 also speeds up the things a littlebit.
        I've read Linux Developers think about replacing atime with realtime (maybe). Is something similiar propably a soltion (except to -o noatime) for FFS2?

        If FFS2 is not yet read such changes may could get done before it's "stable". :)

        But it's hm.. "sad" that, even there was a lot progress, FFS2 isn't (propably) rdy for 4.2. 1TB HDDs will be out there (well they are already).

        I mean: Ok no support for the last fancy things: Nothing wich would interest me in a Server.
        But HDDs are something we all do need. :)

        Comments

        1. By Brynet (Brynet) on

          > 1TB HDDs will be out there (well they are already).

          I'm not sure if this is an issue or not yet, from what I understand (correct me if I'm mistaken..) this only means a "single" slice can't be larger then 1TB.

          Perhaps when "multiple-TB" drives are common, but wouldn't the problem be non-existent as long as you split up your system over multiple disklabels? (Which is recommended IIRC..)

          Anyway, I'm still using a 40 GB drive.. so stop nagging you rich bugger! :P j/k

          Comments

          1. By Anonymous Coward (24.22.214.92) on

            > Anyway, I'm still using a 40 GB drive.. so stop nagging you rich bugger! :P j/k

            500GB disks are only about 100 USD these days, won't be long until 1TB disks are just as cheap.

          2. By Otto Moerbeek (otto) on http://www.drijf.net

            Here are some details about the current state of affairs. This will reflect what will be in 4.2:

            FFF2 support is complete and ready to use. It is not the default and it will not be the default for quite some time. For a lot of systems, it gives no advantage at all to use FFS2.

            BUT: FFS2 filesystems will need to be smaller than 2TB, since the FFS1/2 code is not completely converted to be 64 bit disk block addresses clean yet. The buffer cache code IS converted, so if your dirver supports it, you can go further: disks and partitions can be larger that 1TB. But note that since fsck_ffs of large filesystems need a lot of memory and time, it's not very practical to use very large filesystems. Usage of larger block and fragment sizes reduces this problem, since less inodes are allocated.

            You can also use FFS1 on large (> 1TB) disks, as long as the partition is smaller than 1TB. newfs will take quite some time, though. If the characteristics of the files you will be storing allow it, use larger block and fragment sizes.

            BUT BEWARE: your disk driver may have limits. For example, with ami(4), the maximum logical volume size is 2T. Other drivers may have the same issue. I tested with an arc(4) controllor, which does not have this limitation.

            AND: this is new territory, so testing of your setup is required.

            Maybe I should write a undeadly article about this.

            Comments

            1. By Anonymous Coward (85.178.122.5) on

              > Maybe I should write a undeadly article about this.

              That would be realy great! :-)

              Btw: What if I gonna use FFS2 and later the code Changes to go further into the 64bit only direction.
              Would I need to recreate the FFS2 Partitions or is it just something 4GB RAM Limit (So if OpenBSD supports some day more then 4GB RAM (where I may have more then 4GB RAM and if OpenBSD supports more RAM some day I just build a new kernel, reboot once and get the advantage)?

              Also would you consider to replace atime?
              I've read a lot about it at kerneltrap.org.
              So what's your oppinion about such a "hack".
              The benefits so far (for me as "simple minded user") do look promising.

              But a FFS2-Article at undeadly would be realy great! Proplably with a little "FAQ"-Section or so and maybe a little "What's to do" or "Further Ideas" Part... :-)

              Comments

              1. By Otto Moerbeek (otto) on http://www.drijf.net

                > > Maybe I should write a undeadly article about this.
                >
                > That would be realy great! :-)
                >
                > Btw: What if I gonna use FFS2 and later the code Changes to go further into the 64bit only direction.
                > Would I need to recreate the FFS2 Partitions or is it just something 4GB RAM Limit (So if OpenBSD supports some day more then 4GB RAM (where I may have more then 4GB RAM and if OpenBSD supports more RAM some day I just build a new kernel, reboot once and get the advantage)?

                64 disk block addresses have little to do with the kernel being 64 bit or not. We're not talking about pointers addressing RAM here, but sector numbers of the disk.
                The on-disk data structures will not change if the FFS1/2 code is made 64-bit block address clean.

                > Also would you consider to replace atime?
                > I've read a lot about it at kerneltrap.org.
                > So what's your oppinion about such a "hack".
                > The benefits so far (for me as "simple minded user") do look promising.

                I have little incentive to change atime. You can always mount with noatime if you do not need it. It's semantics should not change: if it is enabled, it should work as it does now.

                > But a FFS2-Article at undeadly would be realy great! Proplably with a little "FAQ"-Section or so and maybe a little "What's to do" or "Further Ideas" Part... :-)

                Comments

                1. By Tomás Prado (201.53.188.140) on

                  What happened to pedro@?

                  Comments

                  1. By anonymous pedro (189.25.30.72) on

                    > What happened to pedro@?

                    gone. in a dictatorship, it is common for people to just disappear

                    Comments

                    1. By Anonymous Coward (69.207.171.114) on

                      > > What happened to pedro@?
                      >
                      > gone. in a dictatorship, it is common for people to just disappear

                      So Brazil is a dictatorship now?

                      Comments

                      1. By Anonymous Coward (206.248.190.11) on

                        > > > What happened to pedro@?
                        > >
                        > > gone. in a dictatorship, it is common for people to just disappear
                        >
                        > So Brazil is a dictatorship now?

                        OpenBSD is.

            2. By Anonymous Coward (24.37.242.64) on

              Maybe I should write a undeadly article about this.

              Please do, I for one would love to hear more too.

            3. By Anonymous Coward (195.71.90.10) on

              i'd realy apreciate an article 'bout this.

            4. By niallo (82.195.149.9) niallo@openbsd.org on http://niallo.net

              Thanks a lot for the clarification Otto. I had been following the 64-bit clean work but was unsure of the exact status in 4.2.

              And of course, thanks for the hard work on this :-)



              > Here are some details about the current state of affairs. This will reflect what will be in 4.2:
              >
              > FFF2 support is complete and ready to use. It is not the default and it will not be the default for quite some time. For a lot of systems, it gives no advantage at all to use FFS2.
              >
              > BUT: FFS2 filesystems will need to be smaller than 2TB, since the FFS1/2 code is not completely converted to be 64 bit disk block addresses clean yet. The buffer cache code IS converted, so if your dirver supports it, you can go further: disks and partitions can be larger that 1TB. But note that since fsck_ffs of large filesystems need a lot of memory and time, it's not very practical to use very large filesystems. Usage of larger block and fragment sizes reduces this problem, since less inodes are allocated.
              >
              > You can also use FFS1 on large (> 1TB) disks, as long as the partition is smaller than 1TB. newfs will take quite some time, though. If the characteristics of the files you will be storing allow it, use larger block and fragment sizes.
              >
              > BUT BEWARE: your disk driver may have limits. For example, with ami(4), the maximum logical volume size is 2T. Other drivers may have the same issue. I tested with an arc(4) controllor, which does not have this limitation.
              >
              > AND: this is new territory, so testing of your setup is required.
              >
              > Maybe I should write a undeadly article about this.
              >
              >

  2. By Antoine Jacoutot (ajacoutot) ajacoutot@openbsd.org on http://www.lphp.org

    Some comments.

    "6. Then I go through the arduous process of upgrading my installed packages. It’s a tough series of commands to type: pkg_add -ui"

    I didn't get the "series of command" part.
    Why don't you just set PKG_PATH then 'pkg_add -ui -F update,updatedepends' ?

    "7. Now with config-less X, there’s nothing in /etc/X11 that I modify, so I rm -Rf /etc/X11 and run: tar -xvzpf xetc42.tgz -C /"

    Hmm... didn't you just remove the beautiful OpenBSD artwork?

    "9. I make sure mergemaster is installed and run: mergemaster -r -t /tmp/foo"

    I would use the '-i' flag too in case new config files were added.

    Comments

    1. By Anonymous Coward (219.90.218.231) on

      > "6. Then I go through the arduous process of upgrading my installed packages. It’s a tough series of commands to type: pkg_add -ui"
      >
      > I didn't get the "series of command" part.
      > Why don't you just set PKG_PATH then 'pkg_add -ui -F update,updatedepends' ?
      >

      I think that's sarcasm.

      Comments

      1. By Anonymous Coward (219.90.218.231) on

        > > "6. Then I go through the arduous process of upgrading my installed packages. It’s a tough series of commands to type: pkg_add -ui"

        Hmm... hitting preview turned the apostrophe into a keycode... I wonder why I hit preview but then didn't review what was there?

        Comments

        1. By Anonymous Coward (195.71.90.10) on

          > > > "6. Then I go through the arduous process of upgrading my installed packages. It’s a tough series of commands to type: pkg_add -ui"
          >
          > Hmm... hitting preview turned the apostrophe into a keycode... I wonder why I hit preview but then didn't review what was there?

          undeadly has a "funny" way of dealing with quoted text.
          someone with more skill than me should have a look at it.

    2. By Mike Erdely (merdely) on http://erdelynet.com/

      > Some comments.
      >
      >> "6. Then I go through the arduous process of upgrading my installed packages.
      >> It’s a tough series of commands to type: pkg_add -ui"
      > I didn't get the "series of command" part.
      > Why don't you just set PKG_PATH then 'pkg_add -ui -F update,updatedepends' ?

      That was sarcasm. pkg_add -ui is incredibly simple.

      >> "7. Now with config-less X, there’s nothing in /etc/X11 that I modify,
      >> so I rm -Rf /etc/X11 and run: tar -xvzpf xetc42.tgz -C /"
      > Hmm... didn't you just remove the beautiful OpenBSD artwork?

      The first command really does remove everything in /etc/X11. The second command puts everything back. Since I don't modify anything in /etc/X11, there's no point in using mergemaster for /etc/X11 too.

      >> "9. I make sure mergemaster is installed and run: mergemaster -r -t /tmp/foo"
      > I would use the '-i' flag too in case new config files were added.

      Thanks for the tip. I'll check that flag out.

      Comments

      1. By Antoine Jacoutot (ajacoutot) on http://www.lphp.org

        > The first command really does remove everything in /etc/X11. The second command puts everything back. Since I don't modify anything in /etc/X11, there's no point in using mergemaster for /etc/X11 too.

        No, the second command does not put everything back as xetcXX.tgz does not contain everything that's under /etc/X11.
        As I said, you removed the beautiful OpenBSD artwork and you should be severely punished for that ;)

        Comments

        1. By Mike Erdely (merdely) on http://erdelynet.com/

          >>The first command really does remove everything in /etc/X11. The second command puts
          >>everything back. Since I don't modify anything in /etc/X11, there's no point in using
          >>mergemaster for /etc/X11 too.
          >No, the second command does not put everything back as xetcXX.tgz does not contain
          >everything that's under /etc/X11.
          >As I said, you removed the beautiful OpenBSD artwork and you should be severely punished
          >for that ;)

          Damn. I should have looked more closely at the x*42.tgz sets. I figured xetc contained everything X related that went into /etc. Silly me.

          I'll add the right thing to my page. (Either use mergemaster for xetc too or also run: tar -xvzpf xbase42.tgz ./etc -C / && tar -xvzpf xshare42.tgz ./etc -C /)

        2. By Gerardo Santana (189.132.68.172) gerardo.santana gmail on

          > > The first command really does remove everything in /etc/X11. The second command puts everything back. Since I don't modify anything in /etc/X11, there's no point in using mergemaster for /etc/X11 too.
          >
          > No, the second command does not put everything back as xetcXX.tgz does not contain everything that's under /etc/X11.
          > As I said, you removed the beautiful OpenBSD artwork and you should be severely punished for that ;)
          >

          Hello Antoine.

          OpenBSD Artwork in /etc? Doesn'it make you wonder why? Artwork belongs more to a "share" directory than to "etc", don't you think so?

      2. By Anonymous Coward (24.91.199.196) on

        , there's no point in using mergemaster for /etc/X11 too.
        >
        > >> "9. I make sure mergemaster is installed and run: mergemaster -r -t /tmp/foo"
        > > I would use the '-i' flag too in case new config files were added.
        >
        > Thanks for the tip. I'll check that flag out.

        If you delete things from the default install like the apache manual, this will put it back though.

  3. By Anonymous Coward (86.148.136.90) on

    Sorry, config-less X? Any links to when this change was made? Thanks

    Comments
    1. Comments

      1. By George Koehler (kernigh) on http://kernigh.pbwiki.com/OpenBSD

        Config-less X is not new, but exists since XFree86 4.4. Read the Xorg(1) manual page, section titled "CONFIGURATION".

        I use config-less X with Xorg 6.9.0 and OpenBSD 4.1; when I have no /etc/X11/xorg.conf file but I run startx, then the X server uses the ati(4) driver for the Radeon in my PowerBook5,4 machine.

        However, config-less X may be new for "most" machines, for which config-less X previously did not work well.

      2. By Anonymous Coward (69.207.171.114) on

        > > Sorry, config-less X? Any links to when this change was made? Thanks
        >
        > http://www.x.org/wiki/Releases/7.2
        > First bullet under features.

        Looking at that page, I personally think that XCB is a bigger deal. Once X toolkits stop using Xlib (although that'll be a long time from now), we can look forward to smaller shlib sizes, better performance, better multi-threading in graphical programs ... It's good to know that people are doing this kind of work on X, and not just switching everything to autoconf. :P

        Comments

        1. By Anonymous Coward (69.207.171.114) on

          > > > Sorry, config-less X? Any links to when this change was made? Thanks
          > >
          > > http://www.x.org/wiki/Releases/7.2
          > > First bullet under features.
          >
          > Looking at that page, I personally think that XCB is a bigger deal. Once X toolkits stop using Xlib (although that'll be a long time from now), we can look forward to smaller shlib sizes, better performance, better multi-threading in graphical programs ... It's good to know that people are doing this kind of work on X, and not just switching everything to autoconf. :P

          Just installed the snapshots, and XCB is missing. What's more, the Xenocara pdf says "XCB is a problem for us". What gives?

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.]