Closed Bug 538474 Opened 15 years ago Closed 15 years ago

[WinCE] Update path fails from 3.6B2->RC1

Categories

(Toolkit :: Application Update, defect)

1.9.2 Branch
ARM
Windows CE
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 527845

People

(Reporter: marcia, Unassigned)

Details

(Whiteboard: [3.6RC1], [nv])

Attachments

(2 files)

Seen while trying to update from B2 to RC1. 1. Factory reset the device so that you have B2 installed. This must be done since uninstall is no longer supported and I test with nightlies. 2. Help->Check for Updates to get the RC1 update. 3. I receive the update offer and apply it, then ask for restart. 4. When it is trying to restart I get a failure. Here are the log results: AUS:SVC gCanUpdate - testing write access \Program Files\Firefox\update.test AUS:SVC gCanUpdate - able to update AUS:SVC readStatusFile - status: failed: 7, path: \Program Files\Firefox\updates\0\update.status UTM:SVC TimerManager:registerTimer - id: search-engine-update-timer UTM:SVC TimerManager:registerTimer - id: places-maintenance-timer Here is an error that is also in the console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Program%20Files/Firefox/components/nsSessionStartup.js :: sss_onWindowOpened :: line 168" data: no]
Summary: [WinCE] Update path fails from B2->RC1 → [WinCE] Update path fails from 3.6B2->RC1
What is the failure at step 4 ?
Please attach the last-update.log from the failed update as well.
The dialog says: Software update failed. The update could not be installed. Please make sure no other copies of Firefox are running on your computer, and then restart Firefox to try again.
EXECUTE ADD \Program Files\Firefox\browserconfig.properties remove failed: -1,0 (\Program Files\Firefox\browserconfig.properties) ### execution failed Huh. Can you verify that this file exists after resetting the device? Can you also see if this problem occurs after reflashing the device from OS image (and not a factory reset)? Almost sounds like something has the file open and is preventing it from being deleted. Does factory reset + reboot a couple of times also cause the problem?
Oh, I wonder if this might be another flavor of bug 527845, the updater fix for that didn't make it in until Beta 3. See if that file is readonly?
I was able to reproduce this on my tegra running Firefox 3.6b2
raymond or marcia, can you provide the info requested in comment #6? Thanks
The \Program Files\Firefox\browserconfig.properties is not a readonly file on my Tegra
I just reflashed the machine I was using and the update still fails going from Beta 2->RC1 on the betatest channel following the same STR In Comment 0.
Marcia / Raymond, can you check the properties of browserconfig.properties? It might be that it has the hidden attribute checked or any other attributes that are different than the other files. I suspect it may be in the image used to install and haven't seen this with nightly builds.
browserconfig.properties on this machine has only the following item checked: archive. The system box is greyed out and both read only and hidden are unchecked. Several other files I checked have the same item "archive" item checked as browserconfig.properties and the same items unchecked as in the comment above.
dolske, is there an easy way for QA to test going from B3 to RC1?
On a fresh flash of the 12/03 OS image, I have a browserconfig.properties which is marked both read-only and hidden. So this is the same problem as bug 527845, error messages are the same. You should be able to uncheck the Read Only attribute on that file before applying the update to make the update run further. [IIRC, there were 2 or 3 read-only files, but I don't remember what they were.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Also, fwiw, I had problems getting the RC1 update to download, it would just sit and spin trying to contact the update server. Not sure what's up with that, presumably I'm doing something wrong.
Not that it matters for app update now but those files shouldn't be marked read-only or hidden. Perhaps a followup bug should be filed to find out what is going on with the packaging / install of the image. I've had a couple instances where downloading as well as going to pages took rather long which I chalked up to the network (not sure if it is the device's network connection or the actual network).
Whiteboard: [3.6RC1] → [3.6RC1], [nv]
I'm fairly sure the read-onlyness is due to changes made by the OS vendor; the files have also been modified [eg, browserconfig.properties points to a MSN homepage.]
That makes sense. It might be a good thing to let them know about it.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: