Closed Bug 742008 Opened 12 years ago Closed 12 years ago

Firefox profiling Nightly (32-bit) fails update on Windows

Categories

(Release Engineering :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: vladan, Assigned: ehsan.akhgari)

Details

(Whiteboard: [updates])

Attachments

(1 file)

Attached file Profile directory
My 32-bit Firefox profiling Nightly consistently fails to apply on updates on Windows 7 with: "Update could not be installed (patch apply failed)".

I've attached a zipped profile.
Do complete updates work?
sounds like bug 732526 maybe
From last-update.log:

SOURCE DIRECTORY C:\Users\workvladan\AppData\Local\Mozilla\Firefox\Profiling\updates\0
DESTINATION DIRECTORY C:\Program Files (x86)\Profiling
failed: 19
calling QuitProgressUI
That is CERT_VERIFY_ERROR, which suggests that the mars are not signed correctly for some reason.
In particular, mar_verify_signatureW is failing.
In particular, mar_verify_signatureW is failing.
^^^ That was a simultaneous post conflict

(In reply to Chris AtLee [:catlee] from comment #1)
> Do complete updates work?

Yes, I am able to download a new Nightly profiling installer and "upgrade" with it.
I think Chris was asking about partial versus full mar files.  In other words, if you download a nightly from a couple of days ago, and do an update (which should download something around 20MB of update data), does the update work?

Please note that "upgrading" using the installer doesn't currently use the same update code path as the regular in-browser updates.
(In reply to Ehsan Akhgari [:ehsan] from comment #8)
> In other words, if you download a nightly from a couple of days ago, and do an update
> (which should download something around 20MB of update data), does the
> update work?

I downloaded the latest ~20MB .mar file, saved it as update.mar in the updates\0\ directory and got the same "Update could not be installed (patch apply failed)" error
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: release → catlee
Whiteboard: [updates]
Ehsan, can you dig into this more? Or maybe Brian can help debug?
Assignee: nobody → ehsan
(In reply to Chris AtLee [:catlee] from comment #10)
> Ehsan, can you dig into this more? Or maybe Brian can help debug?

What do you need me to do here?  I don't know how I would fix the mar signatures for this branch!
are we sure they're bad?
I'm looking into the MARs now, I'll update here when I have info.
(In reply to Chris AtLee [:catlee] from comment #12)
> are we sure they're bad?

Yes, unless you're implying that we might have bugs on the client side, which is outrageous!  ;-)
ehsan++
are you implying there are bugs with the signing!?!?!?!!?
The full and partial MAR from 2012-04-20 verify with DER file from 
toolkit\mozapps\update\updater\nightly_aurora_level3_primary.der

That cert is determined from the logic here by the way:
toolkit\mozapps\update\updater\Makefile.in

I also checked the MARs from 2012-04-03 and 2012-04-04 and they verify properly as well.  

Do you by chance have this registry location?:
SOFTWARE\Mozilla\MaintenanceService\3932ecacee736d366d6436db0f55bce4
It is used for running tests, and if set it will use the xpcshell cert instead of the normal one.
Also if you can get this error again, please give me your updater.exe in a zip attached to this bug.  I'll verify that the embedded cert file is correct.
I tried downloading the 2012-04-02 build which I presume you had since this was first reported on 2012-04-03 and it updated correctly.  Can you confirm that was the build you were using? 

Could you try uninstalling, then re-installing that same build.  Does it work for you?

Is it possibly the mar file was corrupted while being downloaded?
Brian, I assume these last questions are addressed at Vladan, right?
Yes sorry. Comment 17, Comment 18, and Comment 19 were addressed at vladan.
(In reply to Brian R. Bondy [:bbondy] from comment #17)
> Do you by chance have this registry location?:
> SOFTWARE\Mozilla\MaintenanceService\3932ecacee736d366d6436db0f55bce4
> It is used for running tests, and if set it will use the xpcshell cert
> instead of the normal one.

Yup, it turns out this is what was causing the Firefox updates to fail.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: