Bug #1251

/tmp/post_upgrade_command.php is not executing when going from 1.2.3 to 2.0

Added by Adde BC over 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


In 1.2.3 i had a addon named "OpenVPN Status" after upgrade under Status menu i had two "Open VPN"
both of them went to the old addon (and worked) So i figured id'e remove the addon - and i did, this
left one of the OpenVPN in the menu. giving a 404 when trying to access.

To reinstall the addon is impossible because it is no more in the available addons list for 2.0. So
the only way to get rid of the broken item is to edit the config.

Associated revisions

Revision a90896fd (diff)
Added by Jim Pingle about 8 years ago

Move the code to touch needs_package_sync into the shell script portion of the post upgrade command. The PHP portion will fail spectacularly during the 1.2.3-to-2.0 upgrade trying to run the new binaries on the old OS. The shell script part still works. Fixes #1251 enough for what we need. The PHP code can never run properly there, but at least we can trigger the package reinstall and the rest can sort itself out when 2.0 boots the first time.


#1 Updated by Adde BC over 8 years ago

After uppgrading to latest 404 error dissappears...

But the bug remains..

#2 Updated by Jim Pingle over 8 years ago

  • Subject changed from OpenVPN status package on 1.2.3 upgrading to 2.0 to /tmp/post_upgrade_command.php is not executing when going from 1.2.3 to 2.0
  • Priority changed from Low to High

The real problem here is that /tmp/post_upgrade_command.php is not being run after the 1.2.3 to 2.0 upgrade completes.

Because it doesn't run, the file /conf/needs_package_sync is not being touched

Because /conf/needs_package_sync isn't there, the packages aren't reinstalled when booting into 2.0 after the upgrade.

If I boot to single user mode between the 1.2.3 and 2.0 upgrade, and touch /conf/needs_package_sync then the packages reinstall properly, and this package (and others) that only exist on 1.2.3 are removed and not reinstalled, as expected.

#3 Updated by Jim Pingle over 8 years ago

  • Project changed from pfSense Packages to pfSense

This is really a base system problem and not a problem with this package.

#4 Updated by Jim Pingle over 8 years ago

  • Category set to Upgrade
  • Target version set to 2.0
  • Affected Architecture set to All

#5 Updated by Ermal Luçi over 8 years ago

From post_upgrade_command.php

if($g['platform'] == "pfSense" or $g['platform'] == "nanobsd")

Shouldn't that be unconditional?

#6 Updated by Chris Buechler over 8 years ago

Ermal Luçi wrote:

From post_upgrade_command.php

Shouldn't that be unconditional?

Shouldn't run on live CD.

#7 Updated by Jim Pingle about 8 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#8 Updated by Chris Buechler about 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF