pfSense update from the webGUI fails
When running an update from the web interface it can appear to fail and reports "System update failed".
In that situation it may continue to update in the background and will reboot some minutes later. Or it may require the update running for a second time when it then succeeds. You can't see from the gui page which of those situations you're in.
Added simple test to ensure the instance of pfSense-upgrade is the instance started by hte upgrade GUI page, not some other process
#1 Updated by Steve Beaver almost 2 years ago
CHris Linstruth can reproduce the “fails once then succeeds” issue by simply installing 2.4.3 CE and attempting a GUI upgrade. More here: https://netgate.slack.com/files/U12B39VD4/FAP4XGASU/screen_shot_2018-05-15_at_12.04.27_am.png
#2 Updated by Steve Beaver almost 2 years ago
Based on the message that we can see on the GUI it seems that a ‘pfSense-upgrade -c’ call happened to check if there is a newer version available but GUI considered it was the real upgrade process that was running that output is from `pfSense-upgrade -c` for sure It was reported to happen in the past but I was never able to reproduce it.
We need to isolate all places that call pfSense-upgrade -c (including a cronjob) and think about a way to make sure the real upgrade call is running.
#5 Updated by Jim Pingle over 1 year ago
- Status changed from Feedback to New
- Assignee changed from Renato Botelho to Steve Beaver
On an SG-1000 I occasionally get "The update system is busy. Please try again later" message despite starting the upgrade from the GUI. It isn't consistent, however. There may be a timing issue here on busy/slower platforms.
#10 Updated by Steve Beaver over 1 year ago
Debugging shows that the PID file used to determine whether the upgrade process is still running goes away unexpectedly.
$pidfile = $g['varrun_path'] . '/' . $g['product_name'] . '-upgrade.pid';
Reassigning to Renato, who has the upgrade hood open ATM for another issue.