Bug #6137
closed
Old package inc files may cause problems post-upgrade
100%
Description
This is apparently a fairly common problem, and I'm not sure how to address it. I didn't see anything in here or in the release notes, but there are forum posts. Apologies if it is documented and I'm blind...
https://forum.pfsense.org/index.php?topic=109714.msg610841#msg610841
http://blog.stordata.se/index.php/2016/04/13/upgrade-to-pfsense-2-3-breaks-haproxy-how-to-do-it/
I upgraded first, discovered the breakage, uninstalled the 2.3 haproxy package, then checked and there were rather a lot of haproxy-related files still scattered all over the filesystem.
Would it be feasible for the new 2.3 haproxy package to have a subpackage whose postinstall script just goes and cleans up commonly-found left-over files that shouldn't be there anymore? That's my best guess at how to handle this...
Files
Updated by Jim Thompson about 8 years ago
- Assignee changed from Chris Buechler to Renato Botelho
Updated by Chris Buechler about 8 years ago
- Project changed from pfSense Packages to pfSense
- Subject changed from Haproxy fails after 2.2.x to 2.3 upgrade to Old package inc files may cause problems post-upgrade
- Category changed from haproxy to Package System
- Status changed from New to Confirmed
The problem this causes is one of the old haproxy*.inc files make filter_configure_sync hang forever. So it kills the entire system until you remove those inc files.
We probably ought to whack all of the inc files in /usr/local/pkg with the exception of those in base in post-upgrade unless Renato has a better idea. That will prevent the haproxy issue, and possibly any number of other post-upgrade issues related to old package inc files.
Moving to base and package system because it's possibly an issue with much more than haproxy and should have a general fix.
Updated by Renato Botelho almost 8 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset a07d27e544882076e17da718a3dd98a403761b5c.
Updated by Chris Buechler almost 8 years ago
- File config-pkg-upgradetest1.localdomain-20160506013418.xml config-pkg-upgradetest1.localdomain-20160506013418.xml added
- Status changed from Feedback to Confirmed
The upgrade log shows it doing the package uninstall as configured, and it's correctly reinstalled post-upgrade, but it leaves behind the .inc files in /usr/local/pkg/ so it doesn't fix the root issue here.
Also no doubt many inc files hanging around out there that aren't part of an installed package. After uninstalling the packages, it should rm /usr/local/pkg/* minus the files in base.
Basic example config attached for haproxy. Restore to 2.2.6, upgrade to 2.3.1 snapshot. This particular config, having the .inc files hanging around there doesn't hurt anything. But their presence in /usr/local/pkg/ is what will break with many configs.
Updated by Renato Botelho almost 8 years ago
It was my fault, I forgot part of the code commented out. Fixed now.
Updated by Renato Botelho almost 8 years ago
- Status changed from Confirmed to Feedback
Applied in changeset 18bd1ccb8770fc656e80d0cdc0c8900b8a960a18.
Updated by Adam Thompson almost 8 years ago
I think I have two firewalls still running 2.2.x, so I should be able to test in a "real world" scenario.
Can you please advise when this fix hits the public website, and/or provide an upgrade URL I can test with?
(I probably won't be able to do a test upgrade until Tuesday at the earliest... and I'm only going to take one shot at upgrading each firewall, because they're both production systems. At least one of them is i386, not amd64, if that makes any difference.)
Updated by Renato Botelho almost 8 years ago
Adam Thompson wrote:
I think I have two firewalls still running 2.2.x, so I should be able to test in a "real world" scenario.
Can you please advise when this fix hits the public website, and/or provide an upgrade URL I can test with?
(I probably won't be able to do a test upgrade until Tuesday at the earliest... and I'm only going to take one shot at upgrading each firewall, because they're both production systems. At least one of them is i386, not amd64, if that makes any difference.)
You can get 2.3.1-DEVELOPMENT snapshots at https://snapshots.pfsense.org/. All snapshots newer than 20160606-0900 will contain the fix.
Updated by Chris Buechler almost 8 years ago
the removal part was fine. The reinstall post-upgrade wasn't working until my last commit. Leaving to verify once that hits a snapshot.