Closed
Bug 291108
Opened 19 years ago
Closed 15 years ago
Update of existing version attempts a download
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: pe1chl, Unassigned)
Details
Attachments
(6 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050415 Build Identifier: Mozilla/5.0 (any recent Windows version) We have about 250 workstations running Mozilla 1.7.x These are on a LAN that has no direct routing to Internet. Internet access is via a proxy that is setup using a PAC script. When we need to update to the next version (currently 1.7.7) I download the full installer, unpack it to a network directory (this then contains files like BROWSER.XPI), and I patch the CONFIG.INI to set our installation options and add the Dutch language pack. The SETUP.EXE is then started on each workstation and Mozilla updates itself without user interaction. This works OK about 99% of the time. But nearly every time there are one or two workstations where a popup appears that says it is going to download the file "greuninstall.zip", and that machine attempts to directly contact ftp.mozilla.org, which fails because there is no such routing. After a while it displays a popup indicating that a network error occurred. This can be OK'd and it will retry, or CANCEL can be selected on the first popup. Then it continues the install but GRE is not installed so the product will not work. Once in this state Mozilla cannot be installed anymore. Every attempt to uninstall, wipe directories, etc will result in the same error on the next install. After a lot of searching I have found that the only way to get rid of this persistent condition is to remove the Mozilla and mozilla.org registry keys in HKEY_CURRENT_USER\Software. Removing the same keys in HKEY_LOCAL_MACHINE\Software does not fix it. Reproducible: Sometimes Steps to Reproduce: Hard to reproduce. Fails once or twice for 250 installations. (not tied to specific workstation) Expected Results: When during installation some problem occurs that is apparently related to uninstallation of a previous version, the installation should continue (or there should be an option to continue) ignoring this error and installing the new version anyway. Possibly leaving some trash on the system, but a functional new version.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
Maybe we could get a installer log file? I think it lays around somewhere in temp and is called install.log or so... (i couldnt find docs where the log should be).
Reporter | ||
Comment 3•19 years ago
|
||
This will have to wait until the next update round... I did not think about saving such a log and we clear the tempdir at every boot.
Comment 4•19 years ago
|
||
Ok, 1.7.8 was released, maybe you can take a look if you can fetch the install.log file now (if you find a PC where it fails and TEMP hasn't been cleared yet)?
Reporter | ||
Comment 5•19 years ago
|
||
Auto-install will be done this sunday, I will report.
Comment 6•19 years ago
|
||
BTW: I looked it up, the log file is called install_status.log and can either be found in %TEMP%\ns_temp or later in the Mozilla program folder (it gets copied over at some point during the installation).
Reporter | ||
Comment 7•19 years ago
|
||
Reporter | ||
Comment 8•19 years ago
|
||
Reporter | ||
Comment 9•19 years ago
|
||
Reporter | ||
Comment 10•19 years ago
|
||
Ok, today the auto update ran again and it happened again, this time on 3 computers. The file is different this time but the general status is the same. I have added 3 attachments: a dump of the screen, the install_status.log file found in the program files directory, and a suspicious file getarchives.idi found in a subdirectory ns_temp1 in the temp folder. At the moment the install hangs, the status is: - previous version has been removed. program files directory only contains the install_status.log and 3 folders: Plugins (with Java and Acrobat plugins), uninstall (with old logs and uninstaller), and defaults (with many .js files) - temp directory contains a subdir ns_temp, with grw-win32-installer.exe - temp directory also contains ns_temp1 subdir, with these files: -rwxr-xr-x 1 root root 137 May 15 10:24 Archive.lst -rwxr-xr-x 1 root root 32904 May 15 10:24 CONFIG.INI -rwxr-xr-x 1 root root 4344753 May 15 10:24 GRE.XPI -rwxr-xr-x 1 root root 66756 May 15 10:24 GREUNINSTALL.ZIP -rwxr-xr-x 1 root root 5465 May 15 10:24 INSTALL.INI -rwxr-xr-x 1 root root 31436 May 15 10:24 LICENSE.TXT -rwxr-xr-x 1 root root 235520 May 15 10:24 SETUP.EXE -rwxr-xr-x 1 root root 153472 May 15 10:24 SETUPRSC.DLL -rwxr-xr-x 1 root root 270 May 15 10:24 getarchives.idi The getarchives.idi seems to be a file prepared to instruct to download XPCOM.XPI. However, that file is already present on the system in a directory where all files required for installation have been copied (also in a subdir of temp): -rwxr-xr-x 1 root root 358 May 12 18:00 Archive.lst -rwxr-xr-x 1 root root 2678100 May 12 18:00 BROWSER.XPI -rwxr-xr-x 1 root root 163454 May 12 18:00 CHATZILLA.XPI -rwxr-xr-x 1 root root 49751 May 12 18:00 CONFIG.INI -rwxr-xr-x 1 root root 6640 May 12 18:00 DEFLENUS.XPI -rwxr-xr-x 1 root root 5185067 May 12 18:00 GRE-WIN32-INSTALLER.ZIP -rwxr-xr-x 1 root root 118128 May 12 18:00 INSPECTOR.XPI -rwxr-xr-x 1 root root 5477 May 12 18:00 INSTALL.INI -rwxr-xr-x 1 root root 504126 May 12 18:00 LANGENUS.XPI -rwxr-xr-x 1 root root 31436 May 12 18:00 LICENSE.TXT -rwxr-xr-x 1 root root 1711184 May 12 18:00 MAIL.XPI -rwxr-xr-x 1 root root 66859 May 12 18:00 MOZILLAUNINSTALL.ZIP -rwxr-xr-x 1 root root 20510 May 12 18:00 REGUS.XPI -rwxr-xr-x 1 root root 235520 May 12 18:00 SETUP.EXE -rwxr-xr-x 1 root root 153472 May 12 18:00 SETUPRSC.DLL -rwxr-xr-x 1 root root 275976 May 12 18:00 SPELLCHECK.XPI -rwxr-xr-x 1 root root 106 May 15 10:24 Setup.bat -rwxr-xr-x 1 root root 307898 May 12 18:00 TALKBACK.XPI -rwxr-xr-x 1 root root 212485 May 12 18:00 VENKMAN.XPI -rwxr-xr-x 1 root root 602280 May 12 18:00 XPCOM.XPI -rwxr-xr-x 1 root root 352295 Mar 1 2003 de_ch.xpi -rwxr-xr-x 1 root root 355742 Feb 24 2003 de_de.xpi -rwxr-xr-x 1 root root 238691 Feb 22 2003 en_gb.xpi -rwxr-xr-x 1 root root 207637 Mar 1 2003 es_es.xpi -rwxr-xr-x 1 root root 328035 Feb 24 2003 fr_fr.xpi -rwxr-xr-x 1 root root 392318 Mar 1 2003 it_it.xpi -rwxr-xr-x 1 root root 727878 Dec 24 11:55 langnlnl.xpi -rwxr-xr-x 1 root root 514659 Mar 1 2003 nl.xpi Since the previous (1.7.7) install attempt I made the change to first copy those files to the local system (can be seen in the screenshot) and then run the install from there. Before, the install was run directly from the network directory holding these files. I suspected a network problem because of 250 computers simultaneously accessing those files. But if this change has had any effect, the only change is that it now wants to download a different file. The file attempted to download is the same at all 3 failed systems. The systems have downloaded their install files from 2 different servers. Another 240 systems have downloaded and installed the update without problem. Any clue in here?
Reporter | ||
Comment 11•19 years ago
|
||
This screenshot shows what registry entries are present (for the user that attempted the install) after it fails. Those entries cause the failure to re-occur when install is attempted again. When I remove those 2 keys and retry it succeeds.
Comment 12•19 years ago
|
||
Not sure if it matters in any way here, but in your diff of config.ini i see that you added your components in the Component QFA block (between Force Upgrade File0=[SETUP PATH]\components\fullsoft.dll and Random Install Percentage=100 with the comment above). I would recommened that you move your components after the Random Install Percentage, fixing this probably won't solve this bug so :/. Other than that, i can't reproduce this bug here so far (played around with config.ini, added some langpack, installed various 1.7.x versions on top of each other,etc.).
Reporter | ||
Comment 13•19 years ago
|
||
This is probably the result of applying the same patch after this setting has been added in some version. I will change it. Of course the problem is very difficult to reproduce. You could need 100 attempts to see it only once. Investigating the affected machines I saw that earlier version info remained in the registry, and wrote a small cleanup script that I ran on all systems. Maybe it no longer occurs now... although the same old info also appeared in systems that updated correctly. At least with this script (which is run before the install) it should automatically recover when installation is re-tried.
Reporter | ||
Comment 14•19 years ago
|
||
Results when installing 1.7.11: With the improved CONFIG.INI patch and all old versions cleaned out of the registry before installing (only 1.7.8 info present), there were again 2 workstations hanging attempting to download XPCOM.XPI Restarting these workstations fixed it (because I now run the script that deletes the state information from the registry before starting the install, see comment #13).
Updated•18 years ago
|
QA Contact: bugzilla → general
Comment 15•16 years ago
|
||
MozillaAS v1.7.x is not supported anymore. Can you reproduce with SeaMonkey v1.1.9 ?
Version: unspecified → 1.7 Branch
Comment 16•15 years ago
|
||
Seamonkey and Firefox are using a new NSIS based installer. resolving this old bug, please reopen if you still get this with the new installer
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•