Bug #13680
openPackage install scripts run after PHP upgrade produce errors
0%
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.
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.
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.
Updated by Jim Pingle over 1 year 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.
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 23.01 to 23.05
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 23.05 to 23.09
Updated by Jim Pingle over 1 year ago
- Target version changed from 2.7.0 to CE-Next
Updated by Jim Pingle about 1 year ago
- Plus Target Version changed from 23.09 to 24.01
Updated by Jim Pingle about 1 year ago
- Plus Target Version changed from 24.01 to 24.03
Updated by Jim Pingle 7 months ago
- Plus Target Version changed from 24.03 to 24.07
Updated by Jim Pingle 4 months ago
- Plus Target Version changed from 24.07 to 24.08