Project

General

Profile

Todo #10464

Disallow package updates when a system update is available

Added by Craig Leres 10 months ago. Updated 2 days ago.

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

0%

Estimated time:

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.

update.log (7.82 KB) update.log failed update log Craig Leres, 04/16/2020 04:39 PM

History

#1 Updated by Kris Phillips 5 months ago

Hello Craig,

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

#2 Updated by Jim Pingle 4 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.

#3 Updated by Raffi T 3 months 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

#4 Updated by Steve Yates 3 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.

#5 Updated by Renato Botelho 8 days ago

  • Assignee set to Renato Botelho
  • Target version set to CE-Next

#6 Updated by Christian Ullrich 5 days 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 5 days 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 days 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 2 days 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.

Also available in: Atom PDF