-download the netscape installer form sweetlou -gunzip and untar the installer -run installer it will stop in the middle of installation -go to the directory you installed it in and try to run it -you get an error message : Could not obtain CmdLine processing service
Changing component and reassigning
*** Bug 46399 has been marked as a duplicate of this bug. ***
The other one was given this keyword, so I'm pasting it in here.
Grace, You verified other linux installer bugs this morning. Did you observe this behavior? Alek, No core dump?
Unable to reproduce this behavior with this morning's 8am commercial build. Alek, I'll swing by.
Alek didn't have write permissions for the directory he was installing to (/usr/local/netscape). Changing the permissions made the directory accessible and this rectified the situation so he could install successfully.
verifying; can now successfully install now that i have write permissions to the directory
Reopening with a modified summary and nominating for beta 3 and release note in PR2. Samir, we shouldn't fail mysteriously in this situation which might be fairly common on Unix. (Sean, what does the win installer do? This could happen a lot on Win2K as well.) We need to figure out if the engine didn't detect this, the script ignored an error code, or if the linux wizard didn't report it in a clear way.
i don't think it should be reopened because this would only happen on a unix system because what happened is i didn't have write permissions on the directory usr/local/netscape and it didn't delete previous installations leaving 6 copies of the installation in the directory. once we gave write permissions and del;eted everything we were able to install correctly. i don't think its a problem with the build, but with unix permissions. or maybe i don't know what i am talking about =P
XPI_Init() didn't return an error even though it failed to create and instance of the SoftwareUpdate component since autoreg'ing libxpinstall.so failed. If XPI_Init() provided us with any non-NS_OK error we would have gracefully shown an error dialog with an interpreted error string and quit. Autoreg'ing libxpinstall.so failed because XPCOM was trying to load an old version of the library (in a different location under the old structure -- <cwd>/.tmp.xi.N). I do not understand how this could be since we rebooted and tried the installation. If we didn't reboot I could see why this might happen: we don't close libxpistub.so so that XPCOM doesn't get unloaded (dp suggested this fix to get around one seg fault at exit because global destructors from XPCOM fire off but the lib has been unloaded and the global destructor addresses are no longer valid). However, this is mysterious. The current problem this bug is describing: ungraceful error in middle of install is already being handled. Hence, marking worksforme. The other issue still needs to be tracked down though; maybe in a new bug.
see also bug 46558 Jimmy I am writing relnote for that one.
Reassigning QA Contact to Grace. I know Grace knows much more about this topic. :-)