A Google search with:
+Solaris +"The DT messaging system could not be started"
returns 138 hits.

All of the relevant possible solutions are in this document. My apologies for such a long document but I thought I would try to minimize the resolution attempts that I've already tried.

System configuration:
SunOS hercules 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-250

Anything else you need please let me know.
-----------------------------------------------------------------------------------------------------
Error received:

The DT messaging system could not be started.

To correct the problem:
1. Choose [OK] to return to the login screen.
2. Select Failsafe session from the login screen's option menu and log in.
3. Check to see that the hostname is correct in these locations:
1./etc/src.sh
2./etc/hosts
3./usr/adm/inetd.sec
4.Check to see any magic cookie related error messages in these locations:
1. /var/adm/messages
2. $HOME/.dt/errorlog

Attempted resolutions:
1. Checked /etc/hosts
1. File contains:
1. IP address <hostname> loghost
2. etc.
2. Checked the service status
fmri svc:/network/rpc-100083_1/rpc_tcp:default
name 100083
enabled true
state online
next_state none
state_time Thu Nov 16 22:07:58 2006
restarter svc:/network/inetd:default

3. Attempted to delete TT_DB directory to allow ttdbserverd to rebuild as suggested by a post.
1. Post
Thanks to David Foster (foster@bial1.ucsd.edu) for the quick answer, namely:
| This happens when the tool-talk databases get corrupted. Each partition which
| has one of these databases will have a TT_DB directory at its root. The
| fix is to completely delete ALL of these directories (use find to locate
| them) using "rm -rf /dir/TT_DB.
|
| These will be recreated as needed; no need to stop/start anything, or reboot.
| Works like a charm.
thanks also to Stacy Lindberg and Bismark Espinoza for their
replies....
Marc Poulin
2. I have seen other documentation that indicates this is an acceptable step to take if the TT_DB databases get corrupt

3. Ran ttdbck and got the following error:
1. ttdbck: isopen(“./TT_DB/property_table”): No such file or directory
2. Contrary to the documentation that I have seen these directories have not been created automatically at any point. I would assume logging in to CDE would be sufficient to cause rpc.ttdbserverd to startup and create the TT_DB directory and the files.
4. Also, according to Bug Id: 1186212, it is perfectly fine to delete the TT_DB directory to relocate it to a safer directory.
5. Checked the permissions of root's home directory:
1. drwxr-xr-x 50 root root 1536 Nov 21 18:09 /
6. Tried logging in under another account like mysql. Here's the mysql account's home directory:
1. drwxrwxrwx 6 mysql staff 1536 Nov 21 18:13 /home/mysql
7. Executing quota -v root returns “no disk quota for root (uid 0)
8. Content of nsswitch.conf
passwd: files
group: files

# You must also set up the /etc/resolv.conf file for DNS name
# server lookup. See resolv.conf(4).
hosts: files dns

# Note that IPv4 addresses are searched for in all of the ipnodes databases
# before searching the hosts databases.
ipnodes: files dns

networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
9. Available space on volumes
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t10d0s0 9837644 5664829 4074439 59% /
/devices 0 0 0 0% /devices
ctfs 0 0 0 0% /system/contract
proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
swap 1288984 1016 1287968 1% /etc/svc/volatile
objfs 0 0 0 0% /system/object
fd 0 0 0 0% /dev/fd
swap 1288280 312 1287968 1% /tmp
swap 1288016 48 1287968 1% /var/run
/dev/dsk/c0t10d0s7 7060665 3127022 3863037 45% /export/home
/export/home/mysql 7060665 3127022 3863037 45% /home/mysql
10. Don't know if it's relevant but I found a file called rootswup.trc in /tmp
user is registered
HOMEDIR=//.softwareupdate/1770423442
HOMEDIR=//.softwareupdate/1770423442 exists
disable notification flag is off
pid file does not exist
checkRunningNotApp return 1
NO running NotApp process found
in CDE window environment, quits.
11. Another suggestion was
1. Start in Failsafe mode and look your /etc/hosts file if the hostname corresponds to localhost (127.0.0.1).
1. The entry is: 127.0.0.1 localhost
2. Look if you have network connectivity on interface pcn0
1. Unfortunately, I can't check to see anything using ifconfig. There is a Solaris 10 bug in which I can't get the patch for since I don't have a service contract with Sun. However, I can ping servers outside my network. So, I assume the network card is operational.
12. Another poster gave this advice
1. Ok apparently this one was so obtuse that no one knew or so utterly basic that it was just ignored! For future reference, if you don't have a carriage return after the last line of your 'hosts' file bad things can happen!
2. I put 2 lines past the last line and it still didn't come up
13. Another suggestion
1. I have seen this problem a few times. I believe that this is a generic error and does not necessarily point to the suggestions they list. In my case, I was able to resolve it by doing a sys-unconfig
2. I've done this in the past and it hosed up my system so bad that I had to re-install the OS. I'm not going to try this again.

I got what may perhaps be a similar message. When I clicked "OK", I was reverted back to login screen (perhaps cde).

I had previously disconnected the hme0 interface from my dhcp provider and attached it to another router which was supplying dhcp information.

I had however, before doing any of these steps, edited /etc/default/dhcpagent
and removed the "12' from:
PARAM_REQUEST_LIST=1,3,6,15,28,43

So that a hostname may not, by agent, via dhcp server be requested.

Setting hostnames for a system connected to a dhcp server is documented elsewhere - a google search may reveal that.

In spite of my doing the edit in the /etc/default/dhcpagent and as i believe(I'm pretty sure I rebooted), rebooting after doing such edit (this requires a reboot, see dhcpagent man page)
"
For IPv4, the dhcpagent daemon can be configured to request
a particular host name. See the REQUEST_HOSTNAME description
in the FILES section. When first configuring a client to
request a host name, you must perform the following steps as
root to ensure that the full DHCP negotiation takes place:

# pkill dhcpagent
# rm /etc/dhcp/interface.dhc
# reboot
"

I got the message, believing this to be caused by the dhcp server change, I logged in via "command line login" and, I, did, a reboot...

I did not have the issue when the system rebooted and, I was, via, perhaps, CDE, login.

Another system was also moved from one dhcp server to another in a similar manner, however, the login interface on that was, perhaps, Sun's Java...and on that system, I did not, have, the same issue...