Bug #13680: Package install scripts run after PHP upgrade produce errors - pfSense - pfSense bugtracker

Actions

Copy link

Bug #13680

open

Package install scripts run after PHP upgrade produce errors

Added by Steve Wheeler about 2 years ago. Updated about 1 month ago.

Status:

New

Priority:

Normal

Assignee:

Reid Linnemann

Category:

Upgrade

Target version:

CE-Next

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

25.01

Release Notes:

Default

Affected Version:

2.7.0

Affected Architecture:

Description

During the upgrade to 2.7 or 23.11 PHP is upgraded before the pfSense packages are upgraded. That can lead to the situation where the uninstall scripts in a package are incompatible with PHP 8.1 and throw errors.

[6/18] Upgrading pfSense-pkg-squid from 0.4.45_8 to 0.4.45_10...
[6/18] Extracting pfSense-pkg-squid-0.4.45_10: .......... done
Removing squid components...
Menu items... done.
Services... done.
Loading package instructions...

Fatal error: Array and string offset access syntax with curly braces is no longer supported in /usr/local/pkg/squid.inc on line 852
PHP ERROR: Type: 64, File: /usr/local/pkg/squid.inc, Line: 852, Message: Array and string offset access syntax with curly braces is no longer supportedpkg-static: DEINSTALL script failed
pkg-static: Fail to kill all processes:No such process
Saving updated package information...
overwrite!
Loading package configuration... done.
Configuring package components...
Loading package instructions...
Custom commands...
Executing custom_php_install_command()...done.
Executing custom_php_resync_config_command()...done.
Menu items... done.
Services... done.
Writing configuration... done.

That was the cause of: https://redmine.pfsense.org/issues/13641

This can prevent the boot completing.

In the above case a reboot allowed the upgrade to complete but that had to be done at the console because the webgui did not start.

Actions

Copy link

Updated by Reid Linnemann almost 2 years ago

Assignee set to Reid Linnemann

Actions

Copy link

Updated by Jim Pingle almost 2 years ago

This may not be viable for this release but for a while I've thought the upgrade process should be removing all packages before rebooting to the new kernel/world and then installing them again at the end (for example by keeping a to-do list of packages to reinstall).

We could probably avoid several different types of upgrade issues that way, but it may be more complicated to implement than we have time for in this release.

Actions

Copy link

Updated by Reid Linnemann almost 2 years ago

I think we'd be better served by focusing our efforts on performing the complete upgrade in the target boot environment, packages and all, so everything is up-to-date when the new environment starts. Of course this fails to address UFS installs, so we'd either have to live with the status quo there or come up with an analogous concept like a staged upgraded root or something along those lines.

Actions

Copy link

Updated by Jim Pingle almost 2 years ago

Reid Linnemann wrote in #note-3:

I think we'd be better served by focusing our efforts on performing the complete upgrade in the target boot environment, packages and all, so everything is up-to-date when the new environment starts. Of course this fails to address UFS installs, so we'd either have to live with the status quo there or come up with an analogous concept like a staged upgraded root or something along those lines.

Even in that scenario it would still be better to remove the existing packages before doing anything else and then reinstalling them again after. Leaving them in place is likely to cause more issues and there is little (likely no) advantage to leaving them active during the upgrade.

Actions

Copy link