Closed Bug 311099 Opened 15 years ago Closed 15 years ago
Partial update fails, tries full update, then fails to apply that update
1.54 KB, text/plain
1.21 KB, patch
|Details | Diff | Splinter Review|
2.32 KB, patch
|Details | Diff | Splinter Review|
4.78 KB, patch
|Details | Diff | Splinter Review|
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Possibly also bug 306170.
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.
OS: Windows XP → All
Summary: Terrible Daily Update Results → Partial updats fail over to full update then fails to apply that update
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.
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
Attachment #198495 - Attachment mime type: application/octet-stream → text/plain
(In reply to comment #6) > Created an attachment (id=198495)  > 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.
Summary: Partial updats fail over to full update then fails to apply that update → Partial update fails, tries full update, then fails to apply that update
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.
Assignee: nobody → darin
Target Milestone: --- → Firefox1.5
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 on attachment 198498 [details] [diff] [review] v1 patch [fixed-trunk, fixed1.8] NPOTB. I'll update prometheus after it lands.
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.
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.
ok, v1 patch is fixed-on-trunk and 1.8 branch. obviously, it sounds like this doesn't resolve everything going on here.
Flags: blocking1.8b5? → blocking1.8b5+
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.
(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
(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?
(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.
(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?
(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.
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 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. email@example.com
(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?
Attachment #198498 - Attachment description: v1 patch → v1 patch [fixed-trunk, fixed1.8]
Attachment #198528 - Attachment description: patch to removed-files.in to remove redundant lines → patch to removed-files.in to remove redundant lines [fixed-trunk, fixed1.8]
Comment on attachment 198530 [details] [diff] [review] patch to beef up updater.exe (adds more logging) [fixed-trunk, fixed1.8] r=dveditz a=dveditz
Attachment #198530 - Attachment description: patch to beef up updater.exe (adds more logging) → patch to beef up updater.exe (adds more logging) [fixed-trunk, fixed1.8]
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(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.
(In reply to comment #26) installed into a completely new directory after uninstalling 1.4.1. same results.
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.
Is this bug will fix some bug like this one: https://bugzilla.mozilla.org/show_bug.cgi?id=308813 ?
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 firstname.lastname@example.org/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.
(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 email@example.com/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.
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 ?
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
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?
(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.
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).
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.
*** Bug 308813 has been marked as a duplicate of this bug. ***
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.
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.
See http://kb.mozillazine.org/Software_Update for collected information on Software Update.
You need to log in before you can comment on or make changes to this bug.