Project

General

Profile

Actions

Todo #10464

closed

Don't change the current update repo when new releases are available

Added by Craig Leres almost 4 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Low
Category:
Upgrade
Target version:
Start date:
04/16/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Force Exclusion

Description

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.


Related issues

Related to Bug #11452: pkg breakage related to yet to be installed 21.02 base systemDuplicate02/18/2021

Actions
Actions #1

Updated by Kris Phillips over 3 years ago

Hello Craig,

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

Actions #2

Updated by Jim Pingle over 3 years 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.

Actions #3

Updated by Raffi T over 3 years ago

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

Actions #4

Updated by Steve Y over 3 years 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.

Actions #5

Updated by Renato Botelho about 3 years ago

  • Assignee set to Renato Botelho
  • Target version set to CE-Next
Actions #6

Updated by Christian Ullrich about 3 years 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.

Actions #7

Updated by Jim Pingle about 3 years 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.

Actions #8

Updated by Christian Ullrich about 3 years 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.

Actions #9

Updated by Jim Pingle about 3 years 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.

Actions #10

Updated by Christian Ullrich about 3 years 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.

Actions #11

Updated by Christian Ullrich about 3 years ago

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.

Actions #12

Updated by Dr. Phil about 3 years ago

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.

Actions #13

Updated by Steve Y about 3 years 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.

Actions #14

Updated by Viktor Gurov about 2 years ago

  • Related to Bug #11452: pkg breakage related to yet to be installed 21.02 base system added
Actions #15

Updated by Renato Botelho almost 2 years ago

  • Assignee deleted (Renato Botelho)
Actions #16

Updated by Jim Pingle over 1 year ago

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.

Actions #17

Updated by Kris Phillips over 1 year ago

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.

Actions #18

Updated by Patch Public 9 months ago

Imo there are three separate updates pfsense manages
  • 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).

Actions #19

Updated by Alex Kolesnik 9 months ago

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

Actions #20

Updated by Sima Xi 5 months ago

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.

Actions #21

Updated by Craig Leres 4 months ago

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

Actions #22

Updated by Kyle Palmer 4 months ago

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.

Actions #23

Updated by Marcos M 4 months ago

  • Subject changed from Disallow package updates when a system update is available to Don't change the current update repo when new ones are available
  • Status changed from New to Feedback
  • Assignee set to Reid Linnemann
  • Target version changed from CE-Next to 2.8.0
  • Plus Target Version set to 23.09
  • Release Notes set to Force Exclusion

The update check process has changed recently (available in 23.09 and CE dev currently).

Now relevant repos are checked for updates without affecting the current repo itself. This avoids automatically updating (e.g. pkg) against a repo that doesn't have compatible packages (hence no more pkg dynamic library errors). One could still manually change to a dev repo while on a release repo and install packages that way which is sometimes handy when troubleshooting.

Actions #24

Updated by Jonathan Lee 4 months ago

  • File Screenshot 2023-12-01 at 8.56.34 AM.png added
Actions #25

Updated by Jonathan Lee 4 months ago

  • File Screenshot 2023-12-01 at 9.10.33 AM.png added
  • File Screenshot 2023-12-01 at 9.10.51 AM.png added
Actions #26

Updated by Marcos M 4 months ago

  • Subject changed from Don't change the current update repo when new ones are available to Don't change the current update repo when new releases are available
  • Target version changed from 2.8.0 to 2.7.1
Actions #27

Updated by Marcos M 4 months ago

  • File deleted (Screenshot 2023-12-01 at 9.10.51 AM.png)
Actions #28

Updated by Marcos M 4 months ago

  • File deleted (Screenshot 2023-12-01 at 9.10.33 AM.png)
Actions #29

Updated by Marcos M 4 months ago

  • File deleted (Screenshot 2023-12-01 at 8.56.34 AM.png)
Actions #30

Updated by Marcos M 4 months ago

  • File deleted (update.log)
Actions #31

Updated by Marcos M 4 months ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF