Bug #8519
closed
pfSense update from the webGUI fails
Added by Steve Wheeler almost 6 years ago.
Updated over 5 years ago.
Affected Architecture:
All
Description
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.
Files
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.
- Assignee set to Renato Botelho
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Status changed from Feedback to New
- Assignee changed from Renato Botelho to Anonymous
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.
- Status changed from New to 13
- Status changed from 13 to New
I have one test box which hits this on every single update. Always reports failure. Always updates fine in the background.
The machine itself is fast (G1820) but the storage is slow.
- Assignee changed from Anonymous to Renato Botelho
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.
- Status changed from New to Resolved
System was running a modified version.
- Status changed from Resolved to Feedback
- Status changed from Feedback to 13
Since that last commit, systems that were not experiencing problems before now fail to track the updates. They print this and nothing else, but the update continues:
Please wait while the update system initializes
- Status changed from 13 to Feedback
Can't reproduce in VM from 2.4.3 CE to 2.4.3_1, or 2.4.3_1 to 2.4.4 latest snapshot. Is there a specific device, design or configuration this should be tested with?
Not seen any update issues for a few snaps now on a number of boxes.
- Status changed from Feedback to Resolved
I had several hitting this in my lab but only just now getting them onto snaps which included the latest fix. Let's give it another day / batch of updates to see how they all fare. If any are still broken I'll reopen.
All of my hosts that had issues before appear to be OK when upgrading from snaps from early yesterday to the latest available.
Also available in: Atom
PDF
Updated by Anonymous 
Updated by 
Updated by 
Updated by 
