Closed
Bug 1226586
Opened 9 years ago
Closed 9 years ago
Firefox cannot upgrade from version 41 to 42
Categories
(Firefox :: Installer, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: bjacob, Unassigned)
Details
Attachments
(1 file)
3.43 KB,
text/plain
|
Details |
I'm running Firefox 41.0.1 (stable channel) on Mac OSX 10.10.5 on a macbook pro (mid-2014).
Firefox cannot upgrade to version 42. When I restart it, it just shows a messagebox saying the upgrade "failed". This persists after a reboot. I discussed this with Anthony on https://bugzilla.mozilla.org/show_bug.cgi?id=1225610#c2 and here is the log from app.update.log in the Browser Console:
Could not read chrome manifest 'file:///Applications/Firefox.app/Contents/Resources/chrome.manifest'.
UTM:SVC TimerManager:registerTimer - id: xpi-signature-verification
AUS:SVC Creating UpdateService
AUS:SVC gCanCheckForUpdates - able to check for updates
AUS:SVC getCanApplyUpdates - testing write access /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/update.test
AUS:SVC getCanApplyUpdates - testing write access /Applications/Firefox.app/Contents/MacOS/update.test
AUS:SVC getCanApplyUpdates - able to apply updates
AUS:SVC readStatusFile - status: failed: 7, path: /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/updates/0/update.status
Reporter | ||
Comment 1•9 years ago
|
||
$ cat /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/updates/0/update.status
pending
Reporter | ||
Comment 2•9 years ago
|
||
I removed this update.status file, this caused the upgrade to be re-downloaded, but it still failed in the same way.
Reporter | ||
Comment 3•9 years ago
|
||
Tried the "Refresh Firefox..." button in about:support. Still same problem.
Comment 4•9 years ago
|
||
Could you check the ownership and permissions of the Firefox .app bundle (ls -al on the directory where the bundle is located)? Is your user account the owner of the bundle and do you have write access? It could also be that one of the files inside the bundle has an incorrect ownership or permissions. Files in Contents/MacOS or Contents/Resources come to mind.
Updated•9 years ago
|
OS: Unspecified → Mac OS X
Reporter | ||
Comment 5•9 years ago
|
||
Comment 6•9 years ago
|
||
Is it possible that you ran Firefox as root at some point (from an elevated Terminal for example)? It looks like Contents/Resources/browser is owned by root, which could happen if Firefox previously updated when it was running as root. Correcting the ownership there (and everywhere else where a file is owned by root) should fix this.
We are working on elevated updates in bug 394984, but detecting this particular scenario would require additional work.
Reporter | ||
Comment 7•9 years ago
|
||
So, 'browser' belonging to root:wheel is possibly the problem?
This is a corporate machine and we have a "managed software centre" that seems to have taken ownership of my Firefox installation...
It could be, then, that the only thing you could do on your end, is better diagnostics.
Comment 8•9 years ago
|
||
Is it more likely that "managed software centre" has taken ownership of the Firefox installation than the possibility that Firefox was run as root at some point? If that's the case, I'm wondering why "managed software centre" didn't update Firefox yet.
We could (and probably should) improve our permissions check, as this would also come handy when we're trying to detect when an update requires elevation in bug 394984. Robert, what are your thoughts on improving the "canApply" check to recursively check the permissions on the files in the bundle instead of creating the update.test file in the root of the bundle?
Flags: needinfo?(robert.strong.bugs)
Reporter | ||
Comment 9•9 years ago
|
||
I certainly don't remember running Firefox as root.
And today I went in that "managed software centre" and did update Firefox; it just seems that it doesn't auto-update software without user interaction.
I'd close my bug as INVALID at this point, but please do so at your convenience as you're still discussing other things in Comment 8 (thanks for considering this issue, btw).
Comment 10•9 years ago
|
||
(In reply to Benoit Jacob [:bjacob] (mostly away) from comment #9)
> I'd close my bug as INVALID at this point, but please do so at your
> convenience as you're still discussing other things in Comment 8 (thanks for
> considering this issue, btw).
Thanks, Benoit. You may also want to make your corporation aware of this issue with the "managed software centre" handling Firefox. It's certainly not obvious.
Reporter | ||
Updated•9 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Updated•9 years ago
|
Flags: needinfo?(robert.strong.bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•