Although the DISPLAY variable is set when the Application/Gateway/Agent Server installer is executed the GUI fails with the following error: $ ./setup.sh Running with DISPLAY environment variable set to: 192.168.200.195:0.0 Listening for transport dt_socket at address: 12333 May 16, 2012 10:23:06 AM com.bmc.install.product.base.project.runner.ProjectRunner SEVERE: THROWABLE EVENT {Description=[Error]} java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit at java.awt.Font.<clinit>(Unknown Source) |
There are different problems that can generate the "java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit" error when trying to install TSCO via the installation utility. Section I: Missing X-Windows server library packages Installation utility requires the following packages to be installed on the TSCO: Application Server, ETL Engine Server, Gateway Server, Agent where the product is to be installed in order to instantiate the installation GUI:
on RHEL, you can validate if these packages are installed via the following command: rpm -qa | grep [package] Where [package] is the target package name. The following command will install all of the required packages on a machine entitled to download packages from Red Hat's update site: sudo yum install libXi libX11 libXau libXdmcp libXext libXcursor libXrender libXfixes libXtst
Check the DISPLAY variable set within the terminal window where the TSCO Installation is being executed: echo $DISPLAY The DISPLAY variable needs to be set to the hostname and display number of a server running a valid X-Windows display server. Examples of machines that are able to access an X-Windows display request are:
To use ssh X-Windows forwarding you must have some additional OS packages installed on the machine. sudo yum install xorg-x11-xauth This package will install the libXmu and libXt as dependencies. If you are connecting from a Linux or Mac display host, you can use the ssh '-X' flag to enable X-forwarding: ssh -X cpit@BCOAS After successfully logging in via ssh with X-forwarding your DISPLAY variable should be automatically set to something like localhost:##. For example: localhost:10 If in order to do the BCO installation you must then 'su' to another user this X-display won't allow the TSCO installation GUI to connect (it will fail with an 'X11 connection rejected because of wrong authentication" error). In that case you'll need to import your MIT magic cookie from the original user that established the DISPLAY into your 'su' session. To do that: (1) As the original login user run 'xauth list' to get the auth entry for the original user (associated with the ssh X-Windows tunnel) This is one way to do it: For example, the error "MobaXterm X11 proxy: Unsupported authorization protocol" being reported can indicate a problem with the X-Windows token. In one environment this was due to the $HOME directory not existing for the TSCO Installation Owner (and thus the $HOME/.Xauthority file couldn't be created which contains the token).
That actually might be a good test if the system administration team will do it: yum install xorg-x11-apps # That is the RPM package that contains the 'xclock' command There are two benefits to that: (A) You'll get an X-Windows program that you can test outside of the TSCO installer so you'll that you are just dealing with a regular OS level configuration problem (B) The 'xclock' package (xorg-x11-apps) will install all of the dependent packages that are required for the X-Windows display to work on the machine. When confirming any required packages lists it is important to be somewhat suspicious of any 'package requirements' list that doesn't explicit state which OS release versions it is known to be compatible with. For example, RHEL frequently changes which packages are part of the 'core' release (and generally reduces the 'core' package set) and modifies/renames packages so package requirements are often slightly different for each Linux variant and major version. Related Products:
|