Closed Bug 497956 Opened 13 years ago Closed 13 years ago
.0 .0 .6 and older fail integrity check for Tb2 .0 .0 .22 update, and then fail to apply
When checking for updates in Thunderbird 2.0 in the betatest channel, TB downloads the full update for 188.8.131.52, which then fails the integrity check. It then immediately attempts to download it again and gets stuck waiting to apply the download. This was verified in multiple locales on Linux, Win32, and OS X. Full updates to 184.108.40.206 from TB 220.127.116.11 and 18.104.22.168 apply correctly and Build has verified that the bits appear to be correct and exactly the same in all instances of full updates. It is suspected that this is a server problem when TB 2.0 requests updates. Steps to Reproduce 1. Install TB 2.0 2. Edit the channel-prefs.js file in /defaults/pref under TB to have the channel changed from "release" to "betatest" 3. Start TB and check for updates Result: http://img3.imageshack.us/img3/2538/picture2rfu.png - the status keeps animated and the user is never prompted to restart to apply the download (which means it isn't an issue applying the update after download).
13 years ago
additional info: 1) all the build logs files are error free. 2) that the sha512 of the mar files: thunderbird-22.214.171.124.en-US.linux-i686.complete.mar thunderbird-126.96.36.199.ja-JP-mac.mac.complete.mar ...do match the snippets, as expected. Note: these same exact mar files are used when doing updates from TB188.8.131.52->184.108.40.206, and that worked fine. This leads us to believe the actual mar and snippet files are correct. We dont know why they seem to download in some cases, but not others. mrz: Is it possible there is some change in how files are being served? This is before beta, so no files shared out to mirrors yet, all are on local stage. Are there any recent changes to apache/webheads/cache/etc that might cause this? ss: are there any recent changes to updater that might be involved?
raising severity, as this is blocking TB220.127.116.11 going to beta today.
Severity: normal → critical
Taking this back to RelEng. The problem lies in the snippets. This was the first release on this branch that used sha512 sums in the snippets. Apparently earlier version of tb don't support sha512 hashes. We need to regenerate all of the snippets (not the MARs though, those are valid).
Assignee: server-ops → nobody
Component: Server Operations → Release Engineering
QA Contact: mrz → release
13 years ago
Assignee: nobody → joduinn
Severity: critical → blocker
Priority: -- → P1
Thunderbird 18.104.22.168 will update to 22.214.171.124 without issues. TB 126.96.36.199 (the next release despite version numbers) does not update. So the problem occurred after the 188.8.131.52 release.
Oops, backwards. 184.108.40.206 does NOT update but 220.127.116.11 does.
This is due to bug 383390 which was fixed in 18.104.22.168 Prior to the fix nsICryptoHash truncated to 32 bytes which is wrong for sha384 and sha512
Will be fixed by reverting to UPDATE_PACKAGING_R7 and regenerating snippets.
Assignee: joduinn → nthomas
Summary: Thunderbird 2.0 full updates to 22.214.171.124 fail integrity check and then fail to apply → Thunderbird 126.96.36.199 and older fail integrity check for Tb188.8.131.52 update, and then fail to apply
New snippets (using SHA1) now available on the betatest channel. Snippets for beta and release pushes generated and staged. Notes https://wiki.mozilla.org/Releases/Thunderbird_184.108.40.206/BuildNotes#Fix_update_snippets
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.