I just noticed that my 4.5-alpha-2 update from 4.5-alpha-1 on Linux was 50M instead of 2M, so presumably I did not get the incremental version of the MAR. I don't recall seeing any error messages about the incremental failing, but perhaps I blinked and missed it.
Is this an implementation bug? Or did we just not properly deploy the incrementals for 4.5-alpha-2 on the website correctly in some way?
It looks like https://dist.torproject.org/torbrowser/update_2/4.5-alpha-1-4.5-alpha-2-linu... exists and seems to have sane data in it, so perhaps this is actually a bug?
Are incremental updates working for anyone else?
On 12/9/14 7:22 PM, Mike Perry wrote:
I just noticed that my 4.5-alpha-2 update from 4.5-alpha-1 on Linux was 50M instead of 2M, so presumably I did not get the incremental version of the MAR. I don't recall seeing any error messages about the incremental failing, but perhaps I blinked and missed it.
Is this an implementation bug? Or did we just not properly deploy the incrementals for 4.5-alpha-2 on the website correctly in some way?
It looks like https://dist.torproject.org/torbrowser/update_2/4.5-alpha-1-4.5-alpha-2-linu... exists and seems to have sane data in it, so perhaps this is actually a bug?
Are incremental updates working for anyone else?
I just did a quick test on Mac OS 10.9.5 and an incremental update from 4.5-alpha-1 to 4.5-alpha-2 worked fine (4.1 MB update). But maybe it is not working on Linux64 for some reason? I will try that tomorrow unless someone else reports their experience before I get to it.
Also, if you flip the hidden pref app.update.log to true before you check for updates, interesting messages may be logged to the Browser Console.
* Mark Smith mcs@pearlcrescent.com [2014:12:09 23:05 -0500]:
I just did a quick test on Mac OS 10.9.5 and an incremental update from 4.5-alpha-1 to 4.5-alpha-2 worked fine (4.1 MB update). But maybe it is not working on Linux64 for some reason? I will try that tomorrow unless someone else reports their experience before I get to it.
FWIW it worked fine for me on Linux64.
Mike Perry:
I just noticed that my 4.5-alpha-2 update from 4.5-alpha-1 on Linux was 50M instead of 2M, so presumably I did not get the incremental version of the MAR. I don't recall seeing any error messages about the incremental failing, but perhaps I blinked and missed it.
Is this an implementation bug? Or did we just not properly deploy the incrementals for 4.5-alpha-2 on the website correctly in some way?
That might be an implementation bug. I witnessed that, too, on my Tor Browser I generally use for doing things. This is basically what I got as error:
*** AUS:SVC Downloader:onStopRequest - attempting to stage update: Tor Browser 4.5-alpha-2 *** AUS:SVC readStatusFile - status: failed: 4, path: /path/to/torrowser/Browser/updates/0/update.status *** AUS:SVC handleFallbackToCompleteUpdate - install of partial patch failed, downloading complete patch
I was not able to reproduce that on any machine I have for testing (Windows/OS X/Ubuntu/Debian) with a clean 4.5-alpha-1, so I moved on and concluded that the incremental updates are actually working and I just had a local issue. I wonder if getting a better hint about what was going wrong might be a first thing to find the problem.
Georg
On 12/10/14 3:10 AM, Georg Koppen wrote:
That might be an implementation bug. I witnessed that, too, on my Tor Browser I generally use for doing things. This is basically what I got as error:
*** AUS:SVC Downloader:onStopRequest - attempting to stage update: Tor Browser 4.5-alpha-2 *** AUS:SVC readStatusFile - status: failed: 4, path: /path/to/torrowser/Browser/updates/0/update.status *** AUS:SVC handleFallbackToCompleteUpdate - install of partial patch failed, downloading complete patch
I was not able to reproduce that on any machine I have for testing (Windows/OS X/Ubuntu/Debian) with a clean 4.5-alpha-1, so I moved on and concluded that the incremental updates are actually working and I just had a local issue. I wonder if getting a better hint about what was going wrong might be a first thing to find the problem.
The "failed: 4" tells us that the error was CRC_ERROR (see https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/co...).
The update.log file should contain more details, but that may be gone now. You might look around for a file named update.log, backup-update.log, or last-update.log
Looking at the code in toolkit/mozapps/update/updater/updater.cpp, CRC_ERROR is generated when the checksum of a file that needs to be updated does not match what is recorded in the incremental MAR file. In other words, one of the files within your installation that is to be updated has been modified (in which case the only solution is to fail and fallback to a full update that replaces files instead of patching them).
Kathy and I extracted a list of files from https://www.torproject.org/dist/torbrowser/4.5-alpha-2/tor-browser-linux64-4... that would be updated when the incremental MAR was applied (attached). Is it possible that one of those files had been modified by you or Mike? If not, then there must be a bug somewhere.
Mark Smith:
The "failed: 4" tells us that the error was CRC_ERROR (see https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/co...).
The update.log file should contain more details, but that may be gone now. You might look around for a file named update.log, backup-update.log, or last-update.log
Seems I still had a backup-update.log lying around, yay. It is attached.
Georg
On 12/10/14 2:59 PM, Georg Koppen wrote:
Mark Smith:
The "failed: 4" tells us that the error was CRC_ERROR (see https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/co...).
The update.log file should contain more details, but that may be gone now. You might look around for a file named update.log, backup-update.log, or last-update.log
Seems I still had a backup-update.log lying around, yay. It is attached.
Thanks! Your log has:
... EXECUTE PATCH application.ini EXECUTE PATCH TorBrowser/Tor/libgmp.so.10 EXECUTE PATCH TorBrowser/Docs/sources/versions LoadSourceFile: destination file crc -1802735353 does not match expected crc -131947685 // In hex: 0x948C7107 0xF822A35B LoadSourceFile failed ### execution failed ...
This error should mean that at the time the incremental update was being applied, the file TorBrowser/Docs/sources/versions within the existing installation did not have the same contents as the one in the original 4.5-alpha-1 package. The file size must have been the same because the size check comes before the crc check. See the PatchFile::LoadSourceFile() implementation here:
https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/up...
I did check that the "expected crc" value that was logged matches that of a versions file that I extracted from https://archive.torproject.org/tor-package-archive/torbrowser/4.5-alpha-1/to..., so it seems like the incremental MAR file is correct (side note: I had to create a test program that incorporates the code that Mozilla uses to calculate their CRC32 values; the standard crc32 program produced a different result).
It may be difficult to determine at this point, but is it possible that your versions file was not from the final 4.5-alpha-1 build?
Mark Smith:
On 12/10/14 2:59 PM, Georg Koppen wrote:
Mark Smith:
The "failed: 4" tells us that the error was CRC_ERROR (see https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/co...).
The update.log file should contain more details, but that may be gone now. You might look around for a file named update.log, backup-update.log, or last-update.log
Seems I still had a backup-update.log lying around, yay. It is attached.
Thanks! Your log has:
... EXECUTE PATCH application.ini EXECUTE PATCH TorBrowser/Tor/libgmp.so.10 EXECUTE PATCH TorBrowser/Docs/sources/versions LoadSourceFile: destination file crc -1802735353 does not match expected crc -131947685 // In hex: 0x948C7107 0xF822A35B LoadSourceFile failed ### execution failed ...
This error should mean that at the time the incremental update was being applied, the file TorBrowser/Docs/sources/versions within the existing installation did not have the same contents as the one in the original 4.5-alpha-1 package. The file size must have been the same because the size check comes before the crc check. See the PatchFile::LoadSourceFile() implementation here:
https://gitweb.torproject.org/tor-browser.git/tree/toolkit/mozapps/update/up...
I did check that the "expected crc" value that was logged matches that of a versions file that I extracted from https://archive.torproject.org/tor-package-archive/torbrowser/4.5-alpha-1/to..., so it seems like the incremental MAR file is correct (side note: I had to create a test program that incorporates the code that Mozilla uses to calculate their CRC32 values; the standard crc32 program produced a different result).
It may be difficult to determine at this point, but is it possible that your versions file was not from the final 4.5-alpha-1 build?
FWIW, I have the same error in my backup-update.log but for libxul.so instead of versions. When I saw this, I also puzzled as to if I had decided to run an earlier build of 4.5-alpha-1 and forgot about that.
It also looks like it tried to patch libxul.so before versions in my case, and then aborted, so it may have had differences in both places.
-
Erinn Clark -
Georg Koppen -
Mark Smith -
Mike Perry