Closed Bug 125052 Opened 24 years ago Closed 23 years ago

can't install todays build - CRC errors

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: jmd, Assigned: dveditz)

Details

Trying to install todays build with Navigator, PSM, and QFA selected, it emits this error four times: Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. immediatly (ie, nowhere near 100% yet), then throws up a dialog "There were problems attempted to download install files. Retrying. [OK]". That dialog is overwritten 1-2 seconds later by "Installation could not be completed due to CRC errors. Aborting". (Those strings aren't exact). This is 4 install attempts in a row, from one mozilla-i686-pc-linux-gnu-installer.tar.gz downloaded by mozilla, and one copy downloaded by wget. I've had this problem before on certain days builds as well. It was previously crashing installer, but recently a catch was put it to do the dialog thing rather then blow up. Same effect. No mozilla installed. Are the packages being ziped wrong, perhaps?
Does the problem reported in bug 119092 seem like what you are seeing ?
Possibly... there's been intermitent problems like this for a while, but I filed a bug today because it's 100% reproducable.
QA Contact: bugzilla → ktrina
Todays installer works fine. This should NOT be closed, however. This problem has and will come back.
happening again today traced the network, seems the directory doesn't even exsist. 550 /pub/mozilla/nightly/2002-02-16-06-trunk/linux-xpi/xpcom.xpi: No such file or directory. 221 Goodbye. bz on irc mentions the server may have run out of space?
wfm...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
CCing syd Before I verify this, do you think we should figure out why this problem has been reoccurring? Or should it simply be reopened if the problem should come back?
I did a clean install today and I saw the CRC error Build 2002-04-08-06-trunk, custom (all) However, I tried it again and could not reproduce it. Hmmmm.
Updating the summary to remoge "during transfer", all the installer knows is that the CRC errors were found in the archives after the download. They might have started corrupt on the site, been corrupted in transit, corrupted by the installer's end of the networking software, or even misidentified by a bug in the CRC verification code. If you can re-download and have it work that rules out the first possibility. If you try several times and a particular build always appears corrupt that tends to rule out the second. The last possibility could be checked by testing the "corrupt" archives with an independent zip utility, if we could find a way to capture them. We can rule out site corruption for all but late-night automatically created builds -- the smoketest checkers catch that kind of thing before the tree is opened each morning. We do know that bits do get corrupted during downloads--that's why we added the CRC checking--but we're seeing rather a lot more of it than I'd expect.
Summary: can't install todays build - CRC errors during transfer → can't install todays build - CRC errors
Verified WFM. Not 100% reproducible. To be reopened if CRC rrrors reoccur.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.