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.
Plus Target Version:
25.01
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.
- Assignee set to Reid Linnemann
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.
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.
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.
- Plus Target Version changed from 23.01 to 23.05
- Plus Target Version changed from 23.05 to 23.09
- Target version changed from 2.7.0 to CE-Next
- Plus Target Version changed from 23.09 to 24.01
- Plus Target Version changed from 24.01 to 24.03
- Plus Target Version changed from 24.03 to 24.07
- Plus Target Version changed from 24.07 to 24.08
- Plus Target Version changed from 24.08 to 24.11
- Plus Target Version changed from 24.11 to 25.01
Also available in: Atom
PDF
Updated by 
Updated by