pfSense

Hello Craig,

This is not a bug report and we recommend you open a ticket with our support team.

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.

Thanks,
Raffi

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

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.

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.

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.

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.

[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/>

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.

At least now I can't reproduce the spontaneous upgrade, which is good in this case, I suppose. I'm sorry if I was spreading a bit too much panic above, but it did happen after all.

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.

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.

Also worth noting, however this is handled, it should not suppress the list of packages and it must still allow the user to remove packages.

It should only disable the update and reinstall functions.

Internal Redmine 7479 I feel would be a better solution to this problem, rather than making PHP changes. If we split repos by version number like that is saying (I believe Glen is working on this already) it would eliminate the need to hide anything.

• pfsense update: branch set to current should update as new current branch is configured by Netgate centrally.

• Package updates: pfsense should set the branch to the version of pfsense running on the system requesting the package update. Any other package updates should not be readily offered as they may break the locally running version of pfsense (FreeBSD version change). If that information is not available in the repository, then the user should be warned to do their own checking

• Patch updates: pfsense patch update should behave the same as the package update for the same reasons

If uninstalling packages is recommended prior to a pfsense version update, then the pfsense update code should do this by default. With a check-box to disable package uninstall/install should a user have packages required during the update process (where that user chooses to do the package uninstall/install manually).

Same here: pfSense uninstalled the asterisk package without any approval:

[root@gw-01 ~]# grep pkg-stat /var/log/system.log
Jun 29 22:33:20 gw-01 pkg-static[76751]: pfSense-repo upgraded: 2.6.0_11 -> 2.6.0_13
Jun 30 08:39:55 gw-01 pkg-static[82210]: asterisk16-16.29.1 deinstalled
Jun 30 08:39:58 gw-01 pkg-static[82210]: net-snmp-5.9.1_2,1 deinstalled
Jun 30 08:40:00 gw-01 pkg-static[82210]: pfSense-repo upgraded: 2.6.0_13 -> 2.7.0

Jim Pingle wrote in #note-2:

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.

Yes, people using Windows 10 should not suddenly get updates for Windows 11 just because Windows 11 is released. They should still get Windows 10 updates unless they upgrade to Windows 11.

So the solution should not be to make it difficult/impossible to update Windows 10, but to make it so that Windows 10 gets Windows 10 updates, not Windows 11 updates.

Three years later I wake up to find that my SG-3100 has auto-borked itself by automatically updating the pkg package:

pylon 154 # pkg
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

I assume breaking pkg prevented it from doing the same to other packages.

I also see that /usr/local/etc/pkg/repos/pfSense.conf has been updated to point to repos with "v23_09" in their paths.

How is it not a bug that my 23.05.1 box has been automatically reconfigured to get packages built for 23.09 which use a different version of openssl in the base?

In retrospect I see the title I picked for this issue is wrong; really it should be something like, "Do not update the pkg repo config unless the system is actually being updated."

Craig Leres wrote in #note-21:

Three years later I wake up to find that my SG-3100 has auto-borked itself by automatically updating the pkg package:

pylon 154 # pkg
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

I assume breaking pkg prevented it from doing the same to other packages.

I also see that /usr/local/etc/pkg/repos/pfSense.conf has been updated to point to repos with "v23_09" in their paths.

I too have recently encountered this issue. I am new to PFSense and would like to know if there is any way to remediate this error:

(ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg")

Have already tried debugging using the method provided by the official documentation to no avail

(https://docs.netgate.com/pfsense/en/latest/troubleshooting/pkg-broken-database.html)

pkg manager is completely broken at this point and would like to avoid a complete reinstall if possible.