Quote:
recently my Common Desktop environment will not load
What changed? If you know, then suggest you work from there (post what changed and possibly someone can help).
If you don't know, then try the pkgchk command (man pkgchk). It should be able to tell you if something is messed up. You would probably have to just reinstall it to get it working.
Nothing in particular showed up on SunSolve although there is a patch for CDE (108920-15). You could try it.
(Note - I just re-searched on SunSolve and found this)
At the CDE login (dtlogin) window, you have entered your username and password
correctly.
Dtlogin attempts to log you in (e.g., the background changes, a new Xserver
is started, etc.) but then, for no obvious reason, the login fails in one of the
following ways:
1. It abruptly returns to the dtlogin window.
2. It hangs on the welcome banner screen.
3. It takes 3 or 6 minutes to get into CDE.
4. It takes around 10 minutes to get into CDE.
5. It takes around 20 minutes to get into CDE.
6. It takes around 30 minutes to get into CDE.
System hangs with an hourglass on the welcome banner screen
Telnet to the system, if possible, and check the /var/adm/messages file and
/var/dt/Xerrors file.
This document demonstrates different approaches to troubleshooting this problem.
Follow through the steps below to try and isolate the cause.
1) Look at the startlog and errorlog files in $HOME/.dt
The logs may give clues to the cause of the error.
2) Verify whether there is an error in the global customization of CDE
Since CDE is so customizable, it is possible that changes
that have been done to the global customization area has
confused the login.
The command rm -rf /etc/dt removes all the global customization.
Note: Save the /etc/dt first if the changes are important
3) Verify whether there is an error in the local customization of CDE
Remove everything in the directory $HOME/.dt and the file $HOME/.dtprofile
From a command line login or remote telnet connection, move or remove
the directory $HOME/.dt and the file $HOME/.dtprofile.
These files or directories will be recreated upon the user's next CDE login.
4) Check for errors in the users environment
It is possible to put commands in the user's environment that
confuse the CDE login environment.
To prove that this is not the case, either remove or save the following
file depending on the users shell. If you're not sure, do all of the following:
cd $HOME
rm -f .login .cshrc .profile .kshrc
and remove any customization from /etc/profile that has been added. The online
manual pages for the various shells describe what files are used during a login.
As an alternative, set up a local user on the host and try logging in as that
user. If it works, it's a user issue. If not, it's an environment issue.
5) A Permissions or Access problem
After you have removed the customization that could have occurred
as described in the steps above, attempt to login as the root user.
Since access is unrestricted on any local file system, it will prove if the
problem is a permissions problem or something else.
Because logging in as root only checks permissions on a local file system,
verify whether the /usr/dt or /usr/openwin directories are local file systems.
If these directories are NFS mounted from another machine, ensure that they
are mounted and shared with root access.
You can do this on Solaris 2.x with the command:
share -F nfs -o root=machine /usr/dt
Change the machine and the directory to export to be appropriate for your
environment. Refer to the online manual page for share_nfs for further details.
Note: The reason for taking 30 minutes to get into CDE can be caused by NFS
mounting problems.
6) Incorrect tooltalk daemon
It is a possibility, although unlikely, that the CDE installion failed.
If this did occur, then the old OpenWindows tooltalk daemon may still be
being used.
Check that the latest version is installed by looking at the file
/etc/inetd.conf and look for a line similar to below:
For 2.5.1 -
100083/1 stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd
For 2.6 and above -
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd
The important point is the path to /usr/dt/bin/rpc.ttdbserverd
7) Corrupted tooltalk database
The tooltalk database that is used by CDE and openwin may sometimes get corrupted.
This can cause CDE to hang.
Installing the latest tooltalk patch and then cleaning the tooltalk database can
take care of the problem.
Note: 6 and 7 above can be the reason for CDE to hang for approximately10
minutes or hanging on the welcome banner screen with an hourglass.
8) Is or has the disk space reached 100 % in any partition?
In some circumstances, if a file system reaches 100% full the tooltalk
databases can get corrupted. The tooltalk databases, which are located
at each local mount point and are in directories with the name TT_DB, will
need to be cleaned up.
Check SRDB 12729 - "How to clean out the ToolTalk Databases" for detailed
information on how to acheive this.
A similar effect can be seen if a users quota is exceeded.
9) Check what name service is being used?
Look at the file /etc/nsswitch.conf to see what name service is being
used. Look at the hosts line. If it is anything other than
hosts: files
temporarily change that entry as above so that only the /etc/hosts
file is accessed when trying to lookup host information.
Ensure that the /etc/hosts file contains an entry for localhost,
as shown below, and an entry for the machine name.
127.0.0.1 localhost
Double check that the IP address for the machine is the same as
the system IP address. Run the command:
ifconfig -a
to check the interfaces IP addresses. Verify that the first name after the
IP address for the machine is the same as defined in /etc/hostname.* where *
is the name of the interface.
After confirming the details, reboot the system to ensure all processes take
account of the temporary change of name service.
If the login works after that then there is a problem with the previous hosts
map, whether it be DNS, NIS or NIS+. Either locate the specific problem or
change the name service map /etc/nsswitch.conf to have the files entry before
the name service.
For example, for DNS name services the /etc/nsswitch.conf hosts line would be:
hosts: files dns
Note: If the name service is the cause, then it might take 3 minutes
per name services used. So if there are two name services used and
both are before "file", then it might take 6 minutes to resolve, and
hence to get into CDE. If the name service and the tooltalk are the
cause of the problem, then it might take 20 minutes to resolve.
10) Manually start CDE from the command line
Before trying to start the openwin/CDE from command line, check if
there is a graphic mode at all which is needed for the openwin/CDE.
That can be done as follows -
From the command line (i.e., no gui is running), log in as root and start the
CDE environment using the commands below (assumes the root shell is ksh or sh):
# OPENWINHOME=/usr/openwin
# export OPENWINHOME
# $OPENWINHOME/bin/xinit
This just starts the Xserver.
At this point, a window should open with one window with no borders,
from which a window manager can be opened by typing dtwm &, or twm &.
And this confirms that there is graphic mode.
If the above fails, then there is something wrong with the graphic
card or its configuration.
If there is a graphic mode, try opening CDE from the command line by using
the following command -
# $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession
If this fails, does a core dump get generated? Look at it via the symbolic
debugger "debugger" using a command such as:
debugger fullpath_of_program core
> where
> quit
If no core file is generated, try using the truss command to see if you can
identify the error. The command below will truss the processes and store the
truss output in a file in the current directory called logfile:
# truss -aef -o logfile $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession
11) Run pkgchk for any corrupt packages, mostly the SUNWdt* packages.
12) Check for maximum CPU usage, etc by any process.
ps -ef | more
13) Check that the hardware is supported?
14) Re-Install CDE
If you still can't solve the problem, re-install CDE from the CDROM.
This is applicable only for Solaris 2.5.1, as CDE comes in a separate
CD for 2.5.1.
The install-cde script will attempt to remove the previous installation
before installing the packages again.
15) Re-Install OS + CDE
If the problem still is not resolved, the change to the system is extremely
difficult to track down. It may be simpler to just re-install the OS and CDE
from scratch.
Re-install the OS starting with a simple configuration with no networking.
Check that CDE works and then add networking and any name service that is
required until either the problem re-appears or the system is fully functional
again.
