Snapshot problem

[J65nko]

A few hours ago I installed an OpenBSD snapshot in a Linux KVM . After installing it failed to generate an "isakmpd/iked RSA key"
The SSH host keys could not be generated because ssh-keygen could not load the libcrypto.so.30.3
And some other weird errors happened as can be seen in the screenshot:



Because I could not figure out how to configure a serial console to the OpenBSD virtual guest on the Linux KVM Hypervisor and because I noticed a new snapshot got uploaded 45 minutes later, I did not report it to the misc mailing list.

OpenBSD 5.6-current (GENERIC.MP) #572: Mon Nov 17 16:01:55 MST 2014
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Two of the ftp mirrors that I monitor, ftp.eu.openbsd.org and ftp.nluug.nl, still have this defect snapshot. So be careful

 1726 Nov 18  00:15:23 2014 SHA256-stockholm
 1726 Nov 18  01:15:23 2014 SHA256-nluug
 1726 Nov 18  02:01:24 2014 SHA256

The SHA256 of the install56.iso with this bug:

SHA256 (install56.iso) = 68fc7642b0886a1ef573ba141e288a36af1424

[jnutt]

Thanks for this kind of post. I follow current on my laptop but, i'm gonna try to test the install from now on on a separate machine.

[jggimi]

You can also do what IT folks have been doing for decades. Backup your system before attempting an upgrade.

We backup our systems due to fear. We restore them due to panic.

-Anon.

[J65nko]

I have never done an upgrade. "Real men" backup and reinstall or they use RAIC (Redundant Array of Inexpensive Computers) to follow current

[jnutt]

Hi again! Oh, and happy new year!

Sorry for adding another comment to the thread, but.. Do you recommend not upgrading this way? I don't mean to sound impolite but I'm just a user, not an expert like many of you in here.

Currently i'm backing up my root partition daily with the /altroot method, just in case.

I've had no issues for about 5 months; upgrading and then using sysmerge has never failed.

[jggimi]

There's nothing wrong with testing a snapshot before deploying it -- in a virtual machine or on hardware.

I test snapshots on my personal workstation before deploying the same snapshot on any production platform. In the event of a problem -- and they can happen, snapshots are not guaranteed -- I can restore, or repair, and either wait for the next snapshot or build my own personal snapshot from source. [1]

Snapshots are made by developers, and are created for a variety of reasons. On active architectures during some development phases snapshots can be produced several times in a single day. On less active architectures snapshots may be very infrequent.

J65nko was caught by a library mismatch, from a snapshot built during an active library "bump". It can happen, but we -current users are much more likely to see library major/minor dependency issues arise with "snapshot packages", which are not built in sync with any published snapshots.

The altroot facility is a fine way to backup your boot blocks and the root filesystem. But it is not a backup of your libraries (/usr/lib), nor of the programs which call them (/usr/bin, /usr/sbin, /usr/libexec...). Altroot would not provide any recovery from a similar error to the one J65nko experienced. It's a boot block and root filesystem backup facility only.

I'm old fashioned, I use dump(8)/restore(8) for system backups, as well as offsite backup of select critical data [2]. Since the restore(8) program is included with the ramdisk kernel, it's a relatively [3] easy to do a bare metal restoration of a system. I just did one for one of my routers a couple of months ago.

---

[1] Methods are detailed in both FAQ 5 and release(8).

[2] I happen to use Colin Percival's Tarsnap service for select critical data.

[3] Bare metal restores are only easy if the admin is comfortable with fdisk(8), disklabel(8), newfs(8), and installboot(8).

[J65nko]

Your are very lucky then

Although I hardly run into issues like not having a functioning system, I would not recommend to upgrade an existing system without having a good verified backup.

BTW I never upgrade a snapshot, I always reinstall a new one. I used to have 2 Pentium III systems as workstation. Then I did a fresh install on the box with the oldest snapshot. I called this RAIC (Redundant Array of Inexpensive Computers). That way I always had a working system.

Nowadays I first do a test install of a new snapshot in a virtual machine under Linux KVM.

The most common issue is a library version conflict. When you monitor the snapshots you will encounter an average of three snapshots a day of the base system. (except for holiday times). The X install sets are updated at a much lower schedule of once or twice a week.

The building of the snapshot packages from the ports tree, depending on the architecture, takes much more time. So it is quite common that the binary snapshot packages are compiled using a base system and/or X Window libraries that are older than the latest snapshot.

Then you encounter things like:

Can't install libiconv-1.14p1 because of libraries
|library c.77.3 not found
Can't install gettext-0.19.3: can't resolve libiconv-1.14p1
| /usr/lib/libc.so.78.0 (system): bad major
Can't install gettext-0.19.3: can't resolve libiconv-1.14p1
Can't install aspell-0.60.6.1p1: can't resolve libiconv-1.14p1,gettext-0.19.3
Can't install alpine-2.11p3: can't resolve aspell-0.60.6.1p1,gettext-0.19.3,libiconv-1.14p1
Can't install lynx-2.8.9pl1p0 because of libraries
Can't install bzip2-1.0.6p1 because of libraries
Can't install unzip-6.0p5 because of libraries
Can't install xz-5.0.7 because of libraries

I use a set of scripts to monitor the main OpenBSD ftp site and a couple of European mirrors. The output of one these scripts:

Current date : 2015-01-01_05:12_UTC
NOW  date    : 2014-12-31_21:10_UTC
PREV date    : 2014-12-31_03:17_UTC
--------------- NOW ------------------------
 1903 Dec 30  20:31:51 2014 SHA256-stockholm
 1903 Dec 30  20:31:51 2014 SHA256-eu3
 1903 Dec 30  20:31:51 2014 SHA256-bitnl
 1903 Dec 30  20:31:51 2014 SHA256
 1903 Dec 30  21:31:51 2014 SHA256-nluug
--------------- PREV -------------------
 1903 Dec 30  20:31:51 2014 SHA256-stockholm
 1903 Dec 30  20:31:51 2014 SHA256-eu3
 1903 Dec 30  20:31:51 2014 SHA256-bitnl
 1903 Dec 30  20:31:51 2014 SHA256
 1903 Dec 30  21:31:51 2014 SHA256-nluug
--------------- X NOW ----------------------
    15187243 Dec 30 12:20 xbase56.tgz
    39929798 Dec 30 12:21 xfont56.tgz
    18917619 Dec 30 12:21 xserv56.tgz
     4570423 Dec 30 12:21 xshare56.tgz
--------------- X PREV ----------------------
    15187243 Dec 30 12:20 xbase56.tgz
    39929798 Dec 30 12:21 xfont56.tgz
    18917619 Dec 30 12:21 xserv56.tgz
     4570423 Dec 30 12:21 xshare56.tgz
--------------- PKG NOW --------------------
    86944279 Dec 29 04:09 0ad-0.0.17.tgz
   720206249 Dec 29 04:09 0ad-data-0.0.17.tgz
              .... [snip] ...............
      110123 Dec 29 04:30 zziplib-0.13.62.tgz
      164903 Dec 29 04:30 zzuf-0.13p2.tgz
--------------- PKG PREV --------------------
    86944279 Dec 29 04:09 0ad-0.0.17.tgz
   720206249 Dec 29 04:09 0ad-data-0.0.17.tgz
              .... [snip] ...............
      110123 Dec 29 04:30 zziplib-0.13.62.tgz
      164903 Dec 29 04:30 zzuf-0.13p2.tgz

This shows that the packages are older than both the X filesets and base system. When there is no increase in version number of say "libc" than it is no problem. But when there is, you encounter issues with installing binary packages. Of course you can remedy that building the package(s) from ports, but I prefer not to. I just wait or use an slightly older base system snapshot.

[jggimi]

Originally Posted by J65nko

...I never upgrade a snapshot

I've been upgrading from snapshot to snapshot, except for the occasional personal release(8) builds, for at least 7 years. Prior to that I did source upgrades to stay -current.

• Snapshot upgrades take less elapsed time, though with scripting the the build is actually less admin effort to upgrade the build machine. Deployment of personal releases have the same upgrade process as any published snapshot.
• Uncommitted code that requires broad testing can be included in snapshots. Source upgrades eliminated my participation in those tests.

[jnutt]

"RAIC" haha nice.

Thank you both for the replies.