Project

General

Profile

Actions

Bug #13680

open

Package install scripts run after PHP upgrade produce errors

Added by Steve Wheeler 2 months ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Category:
Upgrade
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
23.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 #1

Updated by Reid Linnemann about 2 months ago

  • Assignee set to Reid Linnemann
Actions #2

Updated by Jim Pingle about 1 month 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 #3

Updated by Reid Linnemann about 1 month 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 #4

Updated by Jim Pingle 22 days 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

Also available in: Atom PDF