311099 - Partial update fails, tries full update, then fails to apply that update

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[John Liebson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1

Here is what happened today, as far as I can remember:

1. Automatic updating process from 200510037: After 18 minutes, 1.8 MB
downloaded; killed process.

2. Restarted FF, told it to check for Updates; it downloaded a small .mar file
(380 KB, perhaps?): Applied same, process said that did not work, would download
a complete update.

3. After perhaps five minutes, when the server had never been contacted, I
killed that process, restarted FF.

4. Told FF to look for updates, whereupon it again downloaded the small .mar
file. Curiously, when I applied that update, FF accepted it--except that I was
still running 1003. Never said it was going to download the complete update.

5. Started process once again, this time getting a 6 MB update and, as others
have already stated, that "update" was to the 1003 version that I already was
running.

6. I then downloaded a 5 MB installer (notice that it is smaller than the
update-that-does-not-update. Ran same, am writing this using 200510047. 

I've had other failures, both with Firefox and Thunderbird, but this is the
worst such episode.

Reproducible: Always

Steps to Reproduce:
1. Please see the Details box above.
2.
3.

Actual Results:  
As I reported above.

Expected Results:  
Installed proper automatic update.

I'm marking this as a Blocker, given that such results will discourage others
from continuing to test the Beta releases of FF/TB, and that, as stated above,
I've had other serious failures of the system. In addition, if the system is not
at least closer to perfection, when the release versions of FF/TB 1.5 are
available, there will be an incredible amount of justifiable complaining from users.

One example was an update to TB: I let the automated update run, on a dial-up
system, for approximately two hours. When about 6MB of the file had finally been
downloaded to my computer, the file was automatically erased, so that the
download time was completely wasted. I had to manually download the new update file.

Comment 1

[Peter van der Woude [:Peter6]]

-> NEW

Comment 2

[:Gavin Sharp [email: [e-mail]]]

There are a combination of issues involved, bug 308575 covers some of it, but I
had a similar experience without using an installer build. Bug 310995 and bug
310873 could be somewhat related, I suppose.

Comment 3

[Chase Phillips]

Possibly also bug 306170.

Comment 4

[Tracy Walker [:tracy]]

Testing Fx branch update on Windows and Linux (Mac works fine) 1003 to 1004
suffers from bug 308575, then fails to actually install the full update.  Check
for update (Bug 308575 finds partial update, downloads it, restarts Fx, fails to
apply partial update). Then update finds and downloads full update, restarts Fx.
It then appears to apply full update with progress dialog going to completion,
Fx starts. Check buid ID in About: only to find it's still from 1003.

Comment 5

[John Liebson]

I'm going to tag this on here, as I'm rather tired of fighting with the update
system, and as it may be related to my original entry for this bug: Thunderbird
update is not working today.

I've noticed that the "0" file folder in the TB Updates folder has changed its
time setting several times today, but nothing has ever been entered, nor has
anything been downloaded. [I've reduced the time span for checking for updates,
which is why the 0 file time stamp has changed.]

In TB, a short while ago, I clicked on Help, Check for Updates: The system
states that an update is available, but I've waited approximately ten minutes
for the updater to connect to the server, which it never did.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: update.manifest from manual update

The attached file is produced using 
  http://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
to apply 
  firefox-1.4.1.en-US.win32.partial.2005100307-2005100407.mar
to the appropriate nightly. There are stray ^M before the trailing " on all but
the first remove command.

update.status contains 
 failed
update.log contains 
 failed: 5
 calling QuitProgressUI

Comment 7

[Chase Phillips]

(In reply to comment #6)
> Created an attachment (id=198495) [edit]
> update.manifest from manual update
> 
> The attached file is produced using 
>   http://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
> to apply 
>   firefox-1.4.1.en-US.win32.partial.2005100307-2005100407.mar
> to the appropriate nightly. There are stray ^M before the trailing " on all but
> the first remove command.

Noted.  The first remove command appears to be a "true" command generated via
the diff.  The rest appear to come from the removed-files parsing.  Darin will
come up with a patch that strips those variables of the trailing newlines and I
can pull that onto the partial patch packaging system.

Comment 8

[Chase Phillips]

This bug is an infrastructure bug.  I can rebuild the partial MAR files for the
past day easily after we have this fix in-hand.  We should verify it's fixed
before 1.8b5 (in order to ensure that removed-files works properly) but it's not
a fix we need to include in the client.

Comment 9

[Darin Fisher]

-> me

Comment 10

[Darin Fisher]

Attachment: v1 patch [fixed-trunk, fixed1.8]

This just adds a "| tr -d '\r'" to remove any carriage returns that may appear
in the filename.  I tried to extend my sed call to do the stripping for me, but
my regular expression voodoo isn't that good.  Suggestions welcome, but this
works.

Comment 11

[Chase Phillips]

Comment on attachment 198498 [details] [diff] [review]
v1 patch [fixed-trunk, fixed1.8]

NPOTB.	I'll update prometheus after it lands.

Comment 12

[John Liebson]

I am, of course, happy to see that at least part of the problem is on its way to
a solution. However, I want to reiterate the existence of the incredibly slow
download problem, including the time that TB erased nearly 6MB of downloaded
file. (Not forgetting my Comment #5 in this bug, either.)

Should this problem be split off into another Bugzilla report or ? 

I'll leave that decision to others: I'm a FF/TB user, not a programmer/etc.

Comment 13

[Bradley Chapman (not reading bugmail, still gone but not forever)]

I can also confirm poor update performance, especially when you get behind and
need to sequentially apply a number of updates to reach the latest version.

The 20050929 1.4 build, for example, was chronically incapable of updating
itself; it would download the partial update, fail on restart and then spin
forever trying to download the complete update. Eventually I downloaded a
tarball and updated it manually.

Comment 14

[Darin Fisher]

ok, v1 patch is fixed-on-trunk and 1.8 branch.  obviously, it sounds like this
doesn't resolve everything going on here.

Comment 15

[Chase Phillips]

Retroactive blocking1.8b5+.

Comment 16

[Chase Phillips]

Partial patches from 10/3 to 10/4 are rebuilt now.  I installed 10/3 from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-10-03-08-mozilla1.8/.
After installing, I can partial update to 10/4.

We still need to figure out why complete update was failing for some people.

Comment 17

[Bob Clary [:bc] (inactive)]

(In reply to comment #16)

I installed that build using the installer, attempted to update but the partial
update failed then did the full update and still am stitting on a 10/3 build. If
someone knows what questions to ask, come to #mozqa

Comment 18

[Chase Phillips]

(In reply to comment #17)
> (In reply to comment #16)
> 
> I installed that build using the installer, attempted to update but the partial
> update failed then did the full update and still am stitting on a 10/3 build. If
> someone knows what questions to ask, come to #mozqa

Bob, was it installed into an empty directory or a directory that contained a
pervious installation?

Comment 19

[Bob Clary [:bc] (inactive)]

(In reply to comment #18)

Installed into a directory that had previously had a 1.4 build, but which had
been uninstalled prior to the installation of the 10/3 1.4.1 build.

Comment 20

[Chase Phillips]

(In reply to comment #19)
> Installed into a directory that had previously had a 1.4 build, but which had
> been uninstalled prior to the installation of the 10/3 1.4.1 build.

Believe it or not, that detail helps. :)  Could you try installing into an empty
directory now?

Comment 21

[Bob Clary [:bc] (inactive)]

(In reply to comment #20)

1. uninstalled 1.4.1
2. deleted contents of the directory where it was installed.
3. installed 1.4.1
4. attempted partial update, failed
5. attempted full update, sort of hung on "connecting to server" until I hid the
dialog and waited for the restart dialog to appear.
6. restarted, still at 10/3 ua
7. go to step 5.

Comment 22

[Darin Fisher]

OK, the core problem appears to be that there are repeated lines in
removed-files.in, and that causes the updater to barf.  During its PREPARE phase
it finds that components/compreg.dat exists, and then it tries to remove it
twice.  The second removal fails, which causes the update to fail.  The fix is
to remove the redundant lines from removed-files.in and to beef up the updater
code to prevent this failure from occuring in the future even if the input is "bad".

Patch coming up. 

Comment 23

[Darin Fisher]

Attachment: patch to removed-files.in to remove redundant lines [fixed-trunk, fixed1.8]

Comment 24

[Chase Phillips]

Comment on attachment 198528 [details] [diff] [review]
patch to removed-files.in to remove redundant lines  [fixed-trunk, fixed1.8]

We should alphabetize that list sometime to make it easier to add files to the
list of files to remove.  r+a=[e-mail]

Comment 25

[Darin Fisher]

Attachment: patch to beef up updater.exe (adds more logging) [fixed-trunk, fixed1.8]

Comment 26

[Chase Phillips]

(In reply to comment #21)
> 1. uninstalled 1.4.1
> 2. deleted contents of the directory where it was installed.
> 3. installed 1.4.1
> 4. attempted partial update, failed
> 5. attempted full update, sort of hung on "connecting to server" until I hid the
> dialog and waited for the restart dialog to appear.
> 6. restarted, still at 10/3 ua
> 7. go to step 5.

My understanding of this issue suggests that step 4 should provide you a working
partial update.  If you are still having trouble installing the partial update,
maybe something else is going on in your directory.  Could you try removing the
directory that you installed into or installing into a separate directory?

Comment 27

[Daniel Veditz [:dveditz] back 2026-04-08]

Comment on attachment 198530 [details] [diff] [review]
patch to beef up updater.exe (adds more logging) [fixed-trunk, fixed1.8]

r=dveditz
a=dveditz

Comment 28

[Darin Fisher]

fixed1.8

Comment 29

[IU]

(In reply to comment #26)
> My understanding of this issue suggests that step 4 should provide you a working
> partial update.  If you are still having trouble installing the partial update,
> maybe something else is going on in your directory.  Could you try removing the
> directory that you installed into or installing into a separate directory?

Chase, I too experience this problem on both the Branch and Trunk builds,
irrespective of what directory Firefox is installed in (custom or default), and
irrespective of whether it is a clean install (uninstall and purge directory
contents first) or an install over a previous install.  The only builds that do
not exhibit this problem are the .zip builds.

So many people are experiencing these problems; thus, I highly doubt is has
anything to do with something any one user is doing wrong.  It happened going
from 20050930 to 20051001 and it is happening again today, going from 20051003
to 20051004.  If you are not experiencing this problem, chances are you are
using a .zip build.

Comment 30

[Bob Clary [:bc] (inactive)]

(In reply to comment #26)

installed into a completely new directory after uninstalling 1.4.1. same results.

Comment 31

[Bob Clary [:bc] (inactive)]

one final note in this saga. I uninstalled 1.4.1 from the location last used
(C:\temp\yomama), then reinstalled 1.4.1 from 10/3 in my normal location
(C:\Program Files\mozilla.org\firefox-1.5), when it started after the install it
applied the updates and I now have a build from 10/4. Go figure.

Comment 32

[Jean-Michel Reghem]

Is this bug will fix some bug like this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=308813 ?

Comment 33

[Nick Thomas [:nthomas] (UTC+12)]

Perhaps fallout from this bug, I'm seeing partial updates fail verification and
the updater revert to downloading the complete package. This is for the respun
nightlies 2005100417 and 18, using win32. Manual update attempts give update.log
like this:
 PREPARE PATCH extensions/[e-mail]/components/inspector.dll
 CRC check failed
 LoadSourceFile failed
 failed: -2
 calling QuitProgressUI
The sha1sum for the 18 partial mar matches the one in update.xml

Also, do the partial updates for 2005100307 onwards need regenerating to fix
duplicate remove commands ? I've been working around this by deleting
compreg.dat and xpti.dat from the components just for the restart for the updater.

Comment 34

[Darin Fisher]

(In reply to comment #33)
> Perhaps fallout from this bug, I'm seeing partial updates fail verification and
> the updater revert to downloading the complete package. This is for the respun
> nightlies 2005100417 and 18, using win32. Manual update attempts give update.log
> like this:
>  PREPARE PATCH extensions/[e-mail]/components/inspector.dll
>  CRC check failed
>  LoadSourceFile failed
>  failed: -2
>  calling QuitProgressUI
> The sha1sum for the 18 partial mar matches the one in update.xml

Nick, that error indicates that the old file on disk is not the one that was
expected.  In other words, it is the hash (crc32 checksum) of the existing file
on disk -- and not the contents of the patch itself -- that are wrong.  In your
case, Firefox is doing what it should do; it is downloading a complete update
since the partial update failed.

Comment 35

[Nick Thomas [:nthomas] (UTC+12)]

Ok. I can't reproduce this starting with the 2005100418 build so it's probably
something to do with the mar's made during the bug-fixing process. Sorry for the
false alarm.

Will nightly users need to manually install the build above or later ? Or will
someone (Chase ?) go back and regenerate the partial diffs now that the remove
bugs have been fixed ?

Comment 36

[John Liebson]

Yesterday I downloaded and installed both the Firefox and Thunderbird updates
for 20051004.

This morning, TB kept trying to find updates, finally found one. I installed it,
and found that I was still running 20051004, although I suspect that the
trailing digits had changed. I then manually looked for updates, go another
small one, which gave me 2005100418. After that, TB says that no updates are
available.

For Firefox, I have 2005100407, and FF says that no updates are available. 

In both cases, 20051005 files are shown at ftp.mozilla.org.

I'm not the only person reporting the FF situation, as shown in this thread: 

http://forums.mozillazine.org/viewtopic.php?t=326184

Comment 37

[Jesus Cea]

I'm running Firefox 20051003. The programs finds updates, but the update
procedure fails.

Must I download manually a current daily build, with this issue fixed, or can I
wait a corrected MAR update?

Comment 38

[Chase Phillips]

(In reply to comment #37)
> I'm running Firefox 20051003. The programs finds updates, but the update
> procedure fails.
> 
> Must I download manually a current daily build, with this issue fixed, or can I
> wait a corrected MAR update?

You'll need to grab a later build and install it by hand.  Don't forget to
update the channel to 'nightly' if you wish to do nightly updates again.

Comment 39

[Benjamin Smedberg]

20051004 updates are fixed to point to newer MAR files that actually work. The
partial updates look like they were automatically regenerated (which means that
they should also work).

Comment 40

[Jesus Cea]

Too late. I already downloaded&instaled today build of Thunderbird and Firefox :)

But I checked about two hours ago, with the 20051003 builds, and the problem was
still there.

Comment 41

[Jean-Michel Reghem]

*** Bug 308813 has been marked as a duplicate of this bug. ***

Comment 42

[Worcester12345]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004
Thunderbird/1.4.1 ID:2005100406

Is what I get when I use the Nightly Tester Tools extension, but the "About
Mozilla Thunderbird" shows version 1.5 Beta 2 (20051004)


This was from yesterday. Today it does nothing at all.

Comment 43

[Worcester12345]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004
Thunderbird/1.4.1 ID:2005100406

Is what I get when I use the Nightly Tester Tools extension, but the "About
Mozilla Thunderbird" shows version 1.5 Beta 2 (20051004)


This was from yesterday or the day before. Today it does nothing at all.

Comment 44

[Nick Thomas [:nthomas] (UTC+12)]

See http://kb.mozillazine.org/Software_Update for collected information on
Software Update.