Closed Bug 1396460 Opened 7 years ago Closed 7 years ago

Update failed and broke Nightly

Categories

(Toolkit :: Application Update, defect)

57 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 315278
Tracking Status
firefox57 --- affected

People

(Reporter: pbone, Unassigned)

Details

Attachments

(6 files)

Attached file Directory listing diff. (deleted) —
I was waiting for nightly to download its updates from over the weekend (I opened my computer on Monday 2017-09-04 AEST). I opened the About Nightly window (from the Help menu) and waited until the download completed. WHen I came back to the window it had completed, I clicked "Restart Nightly", the browser reloaded as normal but checking the About Nightly window showed that this was still the version from the 30th of August (same as before) it started downloading the update again. This time when I clicked "Restart Nightly" the browser didn't start, I think I saw the progress bar but don't remember, I also clicked quickly after the download finished (FWIW race conditions with the filesystem?). I opened a terminal and went to /opt/firefox where I keep Nightly. I executed ./firefox and it said it couldn't find libmozsandbox.so, indeed there was no libmozsandbox.so there. I downloaded the package from the website and created a fresh installation, it works normally again. I am now looking in the directories of the different installations. the broken one is missing a lot of lib*.so files. I'll attach the diffs of the directories. I'd be happy to provide more details if required.
This is on Linux... right? In the broken install directory please attach the following: In the updates subdirectory attach the last-update.log and the backup-update.log files if they exist. In the updates/0 subdirectory attach the update.log and the update.status files if they exist.
Flags: needinfo?(pbone)
OS: Unspecified → Linux
Attached file updates/last-update.log (deleted) —
Attached file updates/backup-update.log (deleted) —
Flags: needinfo?(pbone)
Attached file updates/0/update.status (deleted) —
Attached file updates/0/update.log (deleted) —
Yes, this is on Linux Mint 18.1 on x86_64
Hardware: Unspecified → x86_64
In the broken install directory do you have a icudt59l.dat file? If so, could you check if you have write access to it? Thanks!
Flags: needinfo?(pbone)
It should have the same permission as other files such as chrome.manifest in that directory.
$ ls -l icudt59l.dat -rw-r--r-- 1 paul paul 10962384 Aug 27 22:20 icudt59l.dat Yep, it's writable by me and has the same permissions as most of the other files. The files with different permissions are things like directories and executables (a+x).
Flags: needinfo?(pbone)
From the log files the last 3 update attempts failed with unique error codes failed: 64 which is WRITE_ERROR_PATCH_FILE https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/bspatch.cpp#152 and one further down in the function failed: 19 which is CERT_VERIFY_ERROR https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/archivereader.cpp#65 failed: 70 which is WRITE_ERROR_EXTRACT https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/archivereader.cpp#319 and one further down in the function WRITE_ERROR_PATCH_FILE and WRITE_ERROR_EXTRACT are both write errors CERT_VERIFY_ERROR is when signature for the update mar file that was downloaded doesn't verify which is typically due to a corrupt download. Having 3 different errors like this for the last 3 update attempts makes me think it might be a problem with the drive. Could you attach the updates.xml from the broken installations install directory?
Attached file updates.xml (deleted) —
Could it be that a few days ago I ran out of disk space? I don't remember which day it was that I ran out of space but it was around the time I had this problem.
That is the likely cause.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
FWIW I unintentially reproduced this. it definitly happens when the filesystem fills up :-( Danm those firefox build directories on an SSD.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: