Closed Bug 291108 Opened 19 years ago Closed 15 years ago

Update of existing version attempts a download

Categories

(SeaMonkey :: Installer, defect)

1.7 Branch
x86
Windows 2000
defect
Not set
normal

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.
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).
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.
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)?
Auto-install will be done this sunday, I will report.
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).
Attached file install_status.log
Attached file getarchives.idi
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?
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.
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.).
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.
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).
QA Contact: bugzilla → general
MozillaAS v1.7.x is not supported anymore.

Can you reproduce with SeaMonkey v1.1.9 ?
Version: unspecified → 1.7 Branch
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.

Attachment

General

Creator:
Created:
Updated:
Size: