Bug #9410
closed
Package install fails to run from GUI
Added by Jim Pingle about 5 years ago. Updated about 5 years ago.
100%
Description
Attempting to install a package from the GUI fails on the latest 2.5.0 snapshot (2.5.0.a.20190317.1652)
Click "Install" and then "Confirm" and it goes to the installation screen but then does not proceed past "Please wait while the update system initializes"
Updated by Bill Meeks about 5 years ago
I think I found where the problem is with this. It seems to be within the pfsense-upgrade shell script in /usr/libexec. The code starting at Line 1326 in the script which determines the current PHP Major Version and compares it to what I assume is the PHP Major Version used in the new package to be installed fails. When querying the "to be installed package PHP version" it gets back a long list of repeating lines saying "PHP73" instead of single instance of the string "PHP73". When it attempts to compare the value with what it obtained for the current PHP Major Version (which is just a single string of "PHP73") the comparison fails and thus the upgrade script exits with -1 return code. This causes the package installation to never happen.
My pkg requery skills are primitive, so I have not yet found the fix or I would submit it as a pull request. Maybe this will at least give a developer a hint to quickly fix the issue.
The failed package installation attempt leaves a text log in /cf/conf which contains the line:
WARNING: Current pkg repository has a new PHP major version. pfSense should be upgraded before installing any new package.
Updated by Renato Botelho about 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Thanks Bill. I've pushed a fix.
Updated by Bill Meeks about 5 years ago
Renato:
Your fix still does not work. The problem appears to be with the argument "%d" in the _pkg rquery command. That switch scans all dependencies and results in the command iterating a bunch of "php73" strings, one per line of output. That results in a "no-match" condition when the test is made later for current PHP version against the new PHP version.
This is the current line of code:
new_php_pkg=$(_pkg rquery -U %dn $(get_meta_pkg_name) | egrep '^php[0-9]{2}$')
This is the same line but with my fix (notice the argument is just "%n" and not "%dn" and I omit the package name):
new_php_pkg=$(_pkg rquery -U %n | egrep '^php[0-9]{2}$')
When you run this command:
pkg rquery -U %dn pfSense-pkg-suricata-4.1.3
You get back the list of dependent packages. I'm not sure exactly what you intended with the original code. When I run it with a blank package name I get back the list of installed packages on the firewall. I can then "grep" that list for "php73".
Updated by Renato Botelho about 5 years ago
Bill Meeks wrote:
Renato:
Your fix still does not work. The problem appears to be with the argument "%d" in the _pkg rquery command. That switch scans all dependencies and results in the command iterating a bunch of "php73" strings, one per line of output. That results in a "no-match" condition when the test is made later for current PHP version against the new PHP version.This is the current line of code:
[...]This is the same line but with my fix (notice the argument is just "%n" and not "%dn" and I omit the package name):
[...]When you run this command:
[...]You get back the list of dependent packages. I'm not sure exactly what you intended with the original code. When I run it with a blank package name I get back the list of installed packages on the firewall. I can then "grep" that list for "php73".
The fix worked on my tests. %dn is correct there. Meta package is not the package being installed but the main pfSense packate (Called pfSense). %dn is used to track dependencies of pfSense package and check which php flavor it's using.
Can you send me the output of `sh -x /usr/local/libexec/pfSense-upgrade WITH_PARAMETERS_THAT_BREAK_IT` ?
[2.5.0-DEVELOPMENT][root@pfs24-amd64-1.home]/root: pkg rquery -U %dn pfSense | egrep '^php[0-9]{2}$'
php73
[2.5.0-DEVELOPMENT][root@pfs24-amd64-1.home]/root: pfSense-upgrade -i pfSense-pkg-suricata
>>> Installing pfSense-pkg-suricata...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 6 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
pfSense-pkg-suricata: 4.1.2_3 [pfSense]
barnyard2: 1.13_2 [pfSense]
broccoli: 1.97,1 [pfSense]
GeoIP: 1.6.12_3 [pfSense]
python27: 2.7.15 [pfSense]
mysql56-client: 5.6.43 [pfSense]
Number of packages to be installed: 6
The process will require 109 MiB more space.
2 MiB to be downloaded.
[1/5] Fetching pfSense-pkg-suricata-4.1.2_3.txz: .......... done
[2/5] Fetching barnyard2-1.13_2.txz: .......... done
[3/5] Fetching broccoli-1.97,1.txz: .......... done
[4/5] Fetching GeoIP-1.6.12_3.txz: .......... done
[5/5] Fetching mysql56-client-5.6.43.txz: .......... done
Checking integrity... done (0 conflicting)
[1/6] Installing GeoIP-1.6.12_3...
[1/6] Extracting GeoIP-1.6.12_3: .......... done
[2/6] Installing python27-2.7.15...
[2/6] Extracting python27-2.7.15: .......... done
[3/6] Installing broccoli-1.97,1...
[3/6] Extracting broccoli-1.97,1: .......... done
[4/6] Installing mysql56-client-5.6.43...
[4/6] Extracting mysql56-client-5.6.43: .......... done
[5/6] Installing barnyard2-1.13_2...
[5/6] Extracting barnyard2-1.13_2: ...... done
[6/6] Installing pfSense-pkg-suricata-4.1.2_3...
[6/6] Extracting pfSense-pkg-suricata-4.1.2_3: .......... done
Saving updated package information...
done.
Loading package configuration... done.
Configuring package components...
Loading package instructions...
Custom commands...
Executing custom_php_install_command()...Saved settings detected...
Migrating settings to new configuration... done.
Cleaning up after rules extraction... done.
The Rules update has finished.
Generating suricata.yaml configuration file from saved settings.
Finished rebuilding Suricata configuration from saved settings.
Setting package version in configuration file.
done.
Executing custom_php_resync_config_command()...done.
Menu items... done.
Services... done.
Writing configuration... done.
Updated by Bill Meeks about 5 years ago
Never mind. My mistake. Your update did fix it. I had inserted some debugging "echo" statements and noted that the $_meta_pkg variable was blank. I assumed, incorrectly, that it should have been the package being installed instead of pfSense itself. So I tested both with a blank and with pfSense-pkg-suricata-4.1.3 (since I was testing my private repository build of the Suricata GUI) for the package name. That's why it was not working for me. I was also just running the pkg rquery command directly at the shell prompt, so I was not using the get_meta_pkg_name() function. That's why your fix still seemed broken to me. It was my own ignorance of what the variable's value should have been.
I just tested again with your update, and my edits removed, and it worked fine.
Thanks!
Bill
Updated by P L about 5 years ago
I am unable to reinstall Suricata on pfSense latest 2.5.0.a.20190321.0930 . (Suricata warns, "The following input errors were detected: decoder-events.rules seems to be missing!!! Please verify rules files have been downloaded, then go to the Categories tab and save the rule set again.")
The screen at "System -> Package Manager -> Package Installer" remains indefinitely (or I lose patience) at "Please wait while the update system initializes".
I imagine this is related to the above.
Where is the "fix" found that is mentioned? Will this be pushed to an updated pfSense dev version? Would that be installable, given the issue itself?
Updated by Renato Botelho about 5 years ago
P Law wrote:
I am unable to reinstall Suricata on pfSense latest 2.5.0.a.20190321.0930 . (Suricata warns, "The following input errors were detected: decoder-events.rules seems to be missing!!! Please verify rules files have been downloaded, then go to the Categories tab and save the rule set again.")
The screen at "System -> Package Manager -> Package Installer" remains indefinitely (or I lose patience) at "Please wait while the update system initializes".
I imagine this is related to the above.
Where is the "fix" found that is mentioned? Will this be pushed to an updated pfSense dev version? Would that be installable, given the issue itself?
It's pfSense-upgrade version 0.66. It'll be available on public repo together with the next round of 2.5.0 snapshots
Updated by P L about 5 years ago
Update: I am able to delete Suricata but not add (it back again). I am now without Suricata.
How do I get this fix mentioned???
Updated by Bill Meeks about 5 years ago
P Law wrote:
Update: I am able to delete Suricata but not add (it back again). I am now without Suricata.
How do I get this fix mentioned???
You will need to wait on the next snapshot update and then apply that. Or, if you want Suricata back immediately, run this from a shell prompt on the firewall:
pkg install pfSense-pkg-suricata
Updated by P L about 5 years ago
Bill Meeks wrote:
P Law wrote:
Update: I am able to delete Suricata but not add (it back again). I am now without Suricata.
How do I get this fix mentioned???
You will need to wait on the next snapshot update and then apply that. Or, if you want Suricata back immediately, run this from a shell prompt on the firewall:
[...]
Thanks. Backup up with Suricata. Delete and (re-) Add resolved issue mentioned in my original post.
Updated by Jim Pingle about 5 years ago
- Status changed from Feedback to Resolved
This seems solved now. On the latest snapshot I can install packages without any issues.