[SOLVED] Update from OPNsense 15.7.25-amd64 fails

Started by 8191, March 12, 2016, 06:43:42 PM

Previous topic - Next topic
March 12, 2016, 06:43:42 PM Last Edit: March 14, 2016, 09:42:22 AM by franco
Hi,

just wanted to update a OPNsense 15.7.25-amd64 box to 16.1, but the update always fails at the same point:


root@detroid:~ # opnsense-update
Updating OPNsense repository catalogue...
OPNsense repository is up-to-date.
All repositories are up-to-date.
Updating OPNsense repository catalogue...
OPNsense repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (70 candidates): 100%
Processing candidates (70 candidates): 100%
Checking integrity... done (3 conflicting)
Checking integrity... done (0 conflicting)
The following 63 package(s) will be affected (of 0 checked):

...

[6/63] Extracting ca_root_nss-3.22.2: 100%
[7/63] Deinstalling isc-dhcp42-relay-4.2.8...
[7/63] Deleting files for isc-dhcp42-relay-4.2.8:   0%/usr/local/lib/libpkg.so.3: Undefined symbol "openat"


BR,
Manuel

Hi Manuel,

This is FreeBSD ABI breakage at its best from 10.1 to 10.2, geez...

Can you try the following for me?

Edit these lines in /usr/local/sbin/opnsense-update

https://github.com/opnsense/update/blob/master/update/opnsense-update.sh#L143-L146

"pkg" to "pkg-static"

And try again from the GUI


Cheers,
Franco

Thanks, franco, that fixed the update!

Manuel

I will try to push this in, but will have to change pkg to switch back to the old ABI in time for 16.1.7 so that the upgrade path works again. Thanks for reporting this.

This will work again in 16.1.7 with a modified version of pkg that retains the 10.1 ABI compatibility. :)

I just experienced the same problem, but found my own solution (?) before finding this item on the forum. 

This is just a home office firewall, and wasn't getting much attention for a long while.  I had to do several updates in sequence which was all going smoothly.  Then I ran into the problem under discussion. 

As I recall it now, my mitigation went like this (minus all the gratuitous reboots and hair pulling):

I went into /usr/local/etc/pkg/repos/origin.conf and manually changed
url: "pkg+http://pkg.opnsense.org/${ABI}/16.1/latest",
to
url: "pkg+http://pkg.opnsense.org/${ABI}/15.7/latest",

I then rolled pkg back using "pkg bootstrap -f". 

I next locked pkg to the older version (I think it was 1.6.2) and changed the source back to 16.1 and completed the pkg update / pkg upgrade from the root shell.  Finally, I unlocked pkg and allowed it to update itself to the problem version. No problems so far, but maybe the shared lib dep. is still broken and my next update will fail.

This left my system in the following state (once I reached the "no more updates" end condition):

OPNsense 16.1.6-amd64
FreeBSD 10.1-RELEASE-p27
OpenSSL 1.0.2g 1 Mar 2016

I kind of thought I would be at FreeBSD 10.2 at this point as every release note for 16.1 mentions 10.2.

Have I managed to fuddle/finesse myself into a stable/correct configuration, or do I need to make further changes? 

It mostly seems to be running fine right now, but I'm afraid to poke it much until I determine if all these pieces really go together.

March 16, 2016, 07:08:36 AM #6 Last Edit: March 16, 2016, 05:31:44 PM by franco
Hi there,

I will have to say some more about this. The ABI breakage of pkg happened silently and did not affect 16.1 to 16.1.5. It was triggered by the recent DHCP 4.2 -> 4.3 major bump and it seems to do something differently there. Suffice to say it will be back to normal again after today's 16.1.7.

Your update method also works, although it misses the base/kernel like you noticed. We have a tool called opnsense-update for this. :)

Changing the package URL in origin.conf can also be done like so:

# opnsense-update -sn "15.7\/latest"

(it needs an escaped forward slash for sed replacement, but then it works)

Upgrading the kernel/base is done by simply invoking:

# opnsense-update && /usr/local/etc/rc.reboot

Please do not defer the reboot using the internal script, it is essential.

The firmware upgrade or the console option (12) will do all of this portably, and there's also a command for scripting now that does it without all the questions, e.g. for a cron job.

# /usr/local/etc/rc.firmware


Cheers,
Franco

Franco,

Thank you, that's an excellent response. 

I had started to think it was not related to a change in DHCP as my first attempt to work around the problem was to lock all three of the isc-dhcp* packages, and the failure mode remained unchanged. 

I will run the opnsense-update tool right away.

Allan