Disallow package updates when a system update is available
I use a SG-1100 that was running 2.4.4-p3 and I noticed today there were updates for a couple of packages I had installed (acme and bind). I updated these and then noticed that a system update (2.4.5) was available. I attempted to install the update (via the gui) but it failed (see update.log). Additional attempts failed early in the process. I logged in and found that pkg was broken due libcryptoauth.so.3 not being available.
I think my mistake was that I updated packages and got the 2.4.5 version of pkg (or updated some other package) so that pkg or some shared library was linked against libcryptoauth.so.3 which was not present in my pre-upgrade 2.4.4-p3 box.
Would not allowing package updates when a system update is available would prevent this type of foot shootery?
To recover I replaced /usr/bin/pkg /usr/local/sbin/pkg with /usr/local/sbin/pkg-static and /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf with pfSense-repo-244.descr (since it appears that upgrading unconditionally replaces the symlink pfSense.conf in /usr/local/etc/pkg/repos with a link to /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf. Then I performed the upgrade from the serial console. Afterwards I verified that the files I updated had been replaced.
#2 Updated by Jim Pingle 8 months ago
- Tracker changed from Bug to Todo
- Subject changed from Should package updates be allowed when a system update is available? to Disallow package updates when a system update is available
While not a bug per se, it is something we could improve. It would prevent some accidental breakage if users couldn't upgrade packages when the base OS needs an upgrade first.
I would like to request this feature change as well. Prevent package updates when pfSense itself has an update available. Users new to pfSense like myself can easily get burned by this. Had to do a fresh install and restore due to this "rookie" mistake. Something that can kill a system so easily like this shouldn't be tribal knowledge.
#4 Updated by Steve Yates 6 months ago
+1. While the world can't be made completely idiot proof, leading someone down a path of a one-click "upgrade available" without specifying it will (or at best may) break pfSense seems a dangerous thing to dangle. Ideally package updates would be listed only for the installed version of pfSense, but disabling package updates with a note to either upgrade pfSense or change to "previous stable version" is safer for all but experienced pfSense users.
Perhaps a note at the top of the package pages to "always update pfSense first before installing or updating packages to avoid breaking it" could be quickly added with limited testing.
#6 Updated by Christian Ullrich 4 months ago
I think this is the wrong approach. Rather than preventing package updates if a pfSense version upgrade is pending, that version upgrade should not be pending in the first place. If my firmware branch was set to "Current (2.4.5)" last week, it should not suddenly be set to "Current (2.5.0)". Instead, it should now be set to "Previous (2.4.5)" because that is the same version as before.
The branch options have two parts, the name and the version. pfSense currently stays on the same name even if the version associated with it changes; in my opinion, it should stay on the same version and change the name.
#7 Updated by Jim Pingle 4 months ago
If you don't automatically offer the upgrade then the update check on the dashboard and so on is not useful. The firewall would never find an update and the user would have to manually check every time by checking for a new branch and manually changing it.
There are advantages/disadvantages to both approaches -- the purpose of this is to find a better way to prevent problems.
#8 Updated by Christian Ullrich 4 months ago
If you don't automatically offer the upgrade then the update check on the dashboard and so on is not useful.
Why not? What's keeping the dashboard from discovering new update branches on its own? "You are on the current release of your selected branch, but do you know this new version is available?"
Again, in my view the basic problem here is that there is no way to set a pfSense installation to "stay on this version". I only have the choice between the three branches (latest, previous, experimental). Two of them will move the installation away from its current version, leaving me with only one option that represents that current version. Until it suddenly doesn't.
This setup has even wider implications. See for example bug #11478 opened just a few minutes ago. It is currently impossible (without disconnecting it from the Internet) to correctly install pfSense 2.4.5 with a configuration saved before the 2.5.0 release because that configuration has (and must have) its update branch set to "latest". Nobody could be expected to know or predict that restoring a previously saved configuration on the same pfSense version it was saved from would result in a half-upgraded system that simply does not work. Same version, same configuration, different result.
#9 Updated by Jim Pingle 4 months ago
What's keeping the dashboard from discovering new update branches on its own?
There is no mechanism to check it that way -- If that is the way we fix this, then maybe that gets added. The point is it's all centered around the same core problem, and that problem is being addressed here.
We don't need 10 issues with different symptoms and results of the same core issue.
#10 Updated by Christian Ullrich 4 months ago
[First off: This bug currently has priority "low". I suggest raising it to "RED ALERT!"]
Just a quick update: I wrote above that "[i]t is currently impossible (without disconnecting it from the Internet) to correctly install pfSense 2.4.5 with a configuration saved before the 2.5.0 release because that configuration has (and must have) its update branch set to 'latest'."
This was not entirely correct. As it turns out, it is currently impossible (without disconnecting it from the Internet) to:
- correctly install pfSense 2.4.5 with any saved configuration, even if that configuration was saved from an installation where the update branch had already been reset to "previous (2.4.5)"
- restore any saved configuration, even one with the branch reset as above, to an existing 2.4.5 installation
I just attempted restoring a saved config that contains these lines that are not in an older one from before the 2.5.0 release:
<pkg_repo_conf_path>/usr/local/share/pfSense/pkg/repos/pfSense-repo-245.conf</pkg_repo_conf_path> <gitsync> <repositoryurl></repositoryurl> <branch></branch> </gitsync>
I don't know what the
<gitsync/>does, but it was in the saved config, so I guess it must be OK.
The result is this (from the system log):
Feb 27 19:12:08 php-cgi rc.package_reinstall_all: New alert found: PHP ERROR: Type: 64, File: /etc/inc/notices.inc, Line: 444, Message: require_once(): Failed opening required 'Net/Growl/Autoload.php' (include_path='.:/etc/inc:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/') Feb 27 19:12:08 php-cgi rc.package_reinstall_all: PHP ERROR: Type: 64, File: /etc/inc/notices.inc, Line: 444, Message: require_once(): Failed opening required 'Net/Growl/Autoload.php' (include_path='.:/etc/inc:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/') Feb 27 19:12:08 php-cgi rc.package_reinstall_all: New alert found: Package reinstall process finished successfully Feb 27 19:12:07 pkg-static 4977 libxslt upgraded: 1.1.34 -> 1.1.34_1 Feb 27 19:12:07 pkg-static 4977 pfSense upgraded: 2.4.5_1 -> 2.5.0 Feb 27 19:12:07 pkg-static 4977 php74-bz2-7.4.15 installed [many php74 packages installed] Feb 27 19:12:04 pkg-static 4977 php72-session-7.2.29 deinstalled [many php72 packages and others, deinstalled and reinstalled] Feb 27 19:08:11 php-cgi rc.package_reinstall_all: Waiting for Internet connection to update pkg metadata and finish package reinstallation
Somehow, the web UI still works, but the dashboard is currently saying that "[t]he system is on a later version than official release." [Update: It's because despite having updated the PHP packages, what's running is still 7.2. Trying to run 7.4 on the command line results in "/usr/local/sbin/php-fpm: Undefined symbol "alphasort@FBSD_1.5".]
If I was in your place, at this point I would be giving serious thought to pulling the 2.5.0 release until this bug is fixed.
I had a similar issue, with even less of an input from me.
To test my backup process, I saved a config.xml locally and reloaded it.
I was on 2.4.5, with no plans to upgrade to 21.02. But my act of reloading the config, triggered pfSense to upgrade packages - without upgrading pfSense itself. Basically it broke. I had to spend a few unplanned hours just to get back to where I was.
I would call it a bug.
#13 Updated by Steve Yates 3 months ago
Steve Yates wrote:
Perhaps a note at the top of the package pages...could be quickly added with limited testing.
Someone more familiar with the coding/Github/translations can add it, but I was thinking of:
<div class="alert-info"> Caution: only install packages for your version of pfSense to avoid installing later, incompatible versions of software. If you are not on the latest version, select Previous Stable Version in <a href="/system_update_settings.php">System/Update</a> before installing or updating any packages. </div>
...just below the "nav" <ul> on pkg_mgr_installed.php and pkg_mgr.php.
A similar warning could be put on the diag_backup.php page, by the Restore section.
In the last few days I've answered multiple posts in the forum by folks who upgraded a package but were still on 2.4.5, and even 2.4.4.