[ARM64] screenshots@mozilla.org.xpi.patch compressed using --x86 causing “install of partial patch failed, downloading complete patch” error in browser console when updating from Firefox 69.0.2 and above to Firefox 71.0
Categories
(Release Engineering :: Release Automation: Updates, defect)
Tracking
(firefox71 wontfix, firefox72 ?)
People
(Reporter: atrif, Unassigned)
Details
(Keywords: regression)
Attachments
(4 files)
Affected versions
- 71.0 (20191128221751)
Affected platforms
- Win 10 aarch64
Steps to reproduce
- Download Firefox 70.0.1 .zip or .exe.
- Set update channel to “release-localtest” (Mozilla Firefox/defaults/pref/channel-prefs.js).
Expected result
- Update is successfully downloaded and applied and no errors are thrown in the browser console.
Actual result
- After downloading the partial patch, Firefox is downloading again the complete one. The update is successfully downloaded and applied.
Regression Range
- Cannot reproduce when updating from 69.0.1(20190917135527), but reproducible when updating from 69.0.2(20191001234643).
Notes
- This can be reproduced when using BITS and nsIIncremental.
- Attached the console log.
- The issue is reproducible when updating from 69.0.3 (20191009172106), 69.0.2 (20191001234643). Maybe this happens only when the partial patch is downloaded first.
- Not reproducible when updating from Firefox 72.0a1 (20191127215655) to 72.0a1 (20191129094247)
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Comment 2•4 years ago
|
||
Robert, could you have a look at this bug please? Thanks
Comment 3•4 years ago
|
||
After the download of the complete starts and before restarting please perform the following
- Type about:config in the url bar and press return
- Click the "I accept the risk" button if it is displayed
- Type devtools.chrome.enabled in the search box
- Toggle the value from false to true by either double clicking it or via the context menu.
- Open Tools -> Web Developer -> Browser Console
- Copy and paste the following into the text box at the bottom
var fileLocator = Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties); var dir = fileLocator.get("UpdRootD", Ci.nsIFile); dir.reveal();
- In the directory that is opened navigate to the updates subdirectory.
- Attach the last-update.log and the backup-update.log files if they exist.
- In the 0 subdirectory attach the update.log and the update.status files if they exist.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Or better still, can you reproduce using the actual 71.0 release?
Reporter | ||
Comment 5•4 years ago
•
|
||
Hello Robert! Yes, ofc, I'm attaching here all the files but unfortunately, I didn't find the "update.log" file in the "0" subdirectory from step 9.
Also, I reproduced the issue today on the release channel as well when updating from Firefox 70.0.1 (20191030021342) to Firefox 71.0.
If there is anything I can help with please let me know.
Reporter | ||
Comment 6•4 years ago
|
||
Changing the summary accordingly.
Comment 7•4 years ago
|
||
Hi Alexandru, are you using the zip builds? If so, please try to reproduce with an installer build.
Reporter | ||
Comment 8•4 years ago
|
||
Yes I was using the .zip build (In reply to Robert Strong [slack rstrong] (Robert they/them - use needinfo to contact me) from comment #7)
Hi Alexandru, are you using the zip builds? If so, please try to reproduce with an installer build.
Yes, I was using the .zip build with files from comment 5 but it reproduces with the .exe too, installed on default path. Attaching the logs from this too.
Comment 9•4 years ago
|
||
The priority flag is not set for this bug.
:robert.strong.bugs, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 10•4 years ago
|
||
If this only really affects 71, we can close this out as wontfix IMO. But we may want to verify that 72 is really unaffected after it goes to release before we do that.
Comment 11•4 years ago
•
|
||
Bug 1514124 made it so mar files for aarch64 are created without the --x86 filter but for some reason the patch for screenshots@mozilla.org.xpi in the partial mar file is created with the --x86 filter.
Shows that the --x86 filter is present (incorrect) for the screenshots@mozilla.org.xpi.patch file
$ xz -l -v -v /c/moz/bug1600293/mar/browser/features/screenshots@mozilla.org.xpi.patch
/c/moz/bug1600293/mar/browser/features/screenshots@mozilla.org.xpi.patch (1/1)
Streams: 1
Blocks: 1
Compressed size: 388 B
Uncompressed size: 1083.3 KiB (1109308 B)
Ratio: 0.000
Check: CRC64
Stream padding: 0 B
Streams:
Stream Blocks CompOffset UncompOffset CompSize UncompSize Ratio Check Padding
1 1 0 0 388 1109308 0.000 CRC64 0
Blocks:
Stream Block CompOffset UncompOffset TotalSize UncompSize Ratio Check CheckVal Header Flags CompSize MemUsage Filters
1 1 12 0 352 1109308 0.000 CRC64 4d9730e730c69c03 12 -- 332 9 MiB --x86 --lzma2=dict=8MiB
Memory needed: 9 MiB
Sizes in headers: No
Shows that the --x86 filter is not present (correct) for the formautofill@mozilla.org.xpi.patch file
$ xz -l -v -v /c/moz/bug1600293/mar/browser/features/formautofill@mozilla.org.xpi.patch
/c/moz/bug1600293/mar/browser/features/formautofill@mozilla.org.xpi.patch (1/1)
Streams: 1
Blocks: 1
Compressed size: 1384 B
Uncompressed size: 636.0 KiB (651299 B)
Ratio: 0.002
Check: CRC64
Stream padding: 0 B
Streams:
Stream Blocks CompOffset UncompOffset CompSize UncompSize Ratio Check Padding
1 1 0 0 1384 651299 0.002 CRC64 0
Blocks:
Stream Block CompOffset UncompOffset TotalSize UncompSize Ratio Check CheckVal Header Flags CompSize MemUsage Filters
1 1 12 0 1348 651299 0.002 CRC64 860338163f948dbd 12 -- 1325 9 MiB --lzma2=dict=8MiB
Memory needed: 9 MiB
Sizes in headers: No
Reporter | ||
Comment 12•4 years ago
•
|
||
When updating from 71.0-build 5 I hit a different behavior:
After going to Hamburger menu-> Help-> About Firefox the first update download is performed (about 35MB, the partial one). The download is finished and the "Restart to update button" is presented.
After the "Restart to update" button is pressed Firefox is restarted and no update is applied and going back to Hamburger menu-> Help-> About Firefox starts the download again, this time downloading the full patch. Attaching the logs here. Should a new bug be filled?
Updating from 72.0-build3 to 72.0-build4 is successful with no errors but the complete patch is downloaded from the beginning. No partial patch is downloaded.
Comment 13•4 years ago
|
||
That is expected behavior so no bug is needed. What you are seeing is that after staging fails N times staging is disabled.
Updated•4 years ago
|
Updated•10 months ago
|
Description
•