Solved wrong openssl library version required after botched system upgrade

I recently updated from 10.4-RELEASE to 11.2-RELEASE. The upgrade was not clean, as the system ran out of space a couple of times and things got seriously out of whack. There was a rollback that put the system in a weird state. Eventually, I thought I'd gotten it all sorted out. Once it looked like everything was safely 11.2-RELEASE, all ports were updated. They all seem to be running fine. But, now...

First, the obvious errors...
# freebsd-update fetch
Looking up mirrors... 2 mirrors found.
Fetching metadata signature for 11.2-RELEASE from invalid signature.
Fetching metadata signature for 11.2-RELEASE from invalid signature.
No mirrors remaining, giving up.

# portsnap fetch
Looking up mirrors... none found.
Fetching snapshot tag from invalid snapshot tag.
No mirrors remaining, giving up.

OK, so...
 # which openssl

# openssl version
Shared object "" not found, required by "openssl"

I'm guessing that's the root of the issue.

Ports are happily using from the openssl port, so I guess it's only my base commands that have the problem. I do remember seeing the .7 libraries get deleted at some point, probably during a make delete-old.

I have successfully done a make buildworld for the purpose of making a custom kernel. Would a make installworld fix the problem, or is there something weirder going on here? Seems like something isn't clear about which version of the OS is running.

For reference:
# freebsd-version -uk

Any thoughts? System appears to be running fine, but I imagine there are a number of base commands that aren't looking for the right libraries. Not sure how many stealth problems there are. was not the only library that got deleted during the clean-up.
make buildworld and make installworld, both go together to update the base system. Did you reinstall the ports after your upgrade? A lot of programs move in and out of base within releases, and ports needs to be reinstalled.

My version is 11.2-RELEASE-p3, and a week ago, it was p2. Get the latest source through svn.
I did reinstall the ports after the upgrade and they seem to be fine. The issue seems to be with the base commands. I've especially messed around with security/openssl because I thought that might make the libraries come back, but this doesn't seem to be about those libraries.

I only did the make buildworld because I read you were supposed to do that before making a custom kernel. I didn't do a make installworld after that, because I figured the regular freebsd-update would have handled all the base software. I suppose if my source code is good, it wouldn't hurt to try. Probably.

I can't get to patch level 3 because all my upgrade tools are nonfunctional, presumably due to looking for the wrong libraries.
Delete everything under /var/db/freebsd-update and try:

freebsd-update -r 11.2-RELEASE upgrade

If it still gives you signature errors you can try another server, the mirrors 4 and 5 are known to be problematic for some people:

freebsd-update -s -r 11.2-RELEASE upgrade
If it still fails you can do the installworld routine:

make -C /usr/src installworld
mergemaster -i
make -C /usr/src delete-old
make -C /usr/src delete-old-libs

Do pay special attention to options offered by mergemaster(8), you can still botch up your system if you do the merge wrong.

After that you're pretty much forced to use make buildworld buildkernel method for updating your system because freebsd-update(8) won't be able to track the changes anymore because you rewrote all the system files with unknown versions.
# freebsd-update -r 11.2-RELEASE upgrade
freebsd-update: Cannot upgrade from 11.2-RELEASE to itself

Is there a way to force it?
Cool. But now we're back to the original problem...

# freebsd-update -r 11.2-RELEASE --currently-running 11.1-RELEASE-p11 upgrade
Looking up mirrors... 2 mirrors found.
Fetching public key from done.
Fetching metadata signature for 11.1-RELEASE from invalid signature.
Fetching metadata signature for 11.1-RELEASE from invalid signature.

Can I just soft link the nonexistent to for the moment to see if it will get the thing going? I assume there might be similar missing libraries, but I could temporarily soft link them as well.
By the way, your system ran out of space during the first upgrade? That's a good sign that you should just back up your configuration and re-install from scratch. The default partitioning from a few years back is no longer good for holding even the two kernels that have to be installed at the same time during the upgrade.
The softlink might work but then again the major version of the library was changed because there was an API/ABI change between the versions so you can't trust the newer library to be 100% backwards compatible.
The plan is to update the hardware on this system, but for now I just want it running safe code.

Changing the softlinks did allow the freebsd-update commands to work, but I ran into the problem described in this thread again so I gave trying the suggested update above up and just did a simple freebsd-update fetch ; freebsd-update install which worked normally.

So I guess now my question is more philosophical. What is it that makes the base commands look for version 7 of the libraries instead of version 8 or version 9? It's likely that there is a common source for this problem.

Also, for the record...
# freebsd-version -uk
Last edited:
If a command is looking for older version of a library than what the base system offers after the upgrade it simply means that the upgrade wasn't complete and some binaries were not upgraded.
So, a make buildworld (assuming I have the right source), would be the most effective way to get a new system?

Or is there a relatively clean way to just get all the binaries, regardless of what files are currently there? freebsd-update seems concerned with moving from one distinct state to another, but we don't really know the current state of the system.
I did the make buildworld and it seems to have taken care of all the problems. Not sure how the bad binaries got there (or didn't get replaced), but things seem OK now. A freebsd-update did a reasonable thing (apparently updating from patch level 2 to 3), so the command not only ran when it didn't before, it seemed to run properly.

Still not sure exactly how everything got so screwed up in the first place, but I seem to be in a safe place now.

To take a step back and address the subject of this then, the reason openssl wanted the wrong libraries (and other commands based on it didn't work) was simply that I had a bad world. That is, the binaries themselves were the wrong version, as you suspected.

It wasn't an issue of a bad config or missing libraries or uninstalled ports or soft links (at least those weren't the root of the problem), it was just that things were out of sync and I probably had 10.4 binaries hanging around while the system thought they were 11.2.