INFODOC ID: 15402 Tips for Troubleshooting Booting of JavaStation 1
SYNOPSIS: Tips for Troubleshooting Booting of JavaStation 1
DETAIL DESCRIPTION:
JavaStation Booting Details and Troubleshooting
Note: Also see Infodoc 15404 for information on usage of the tools that can
help you with this (eg snoop, tip, pntadm)
Purpose
This document explains how to trouble shoot JavaStation booting problems.
It has nothing to do with Java and very little to do with JavaOS itself.
It is mostly about server and network configuration.
It assumes you are trying to boot the JavaStation from a Solaris 2.5 or
later boot server. Other booting configurations are unsupported, although
the dependency is really on network protocols, not a particular server type.
Terminology :
(boot) server - Solaris 2.5 or 2.5.1 SPARC system on which SUNWjdse is
installed, possibly as part of the Netra J installation
JavaStation : the Sun thin-client of network computer - aka
MrCoffee - the codename fro the hardware
JavaOS : codename kona : the operating system for the JavaStation.
Getting this to a running state is the subject of this document.
(network) protocol : A TCP/IP protocol used by the JavaStation.
eg, RARP, TFTP, BOOTPARAM, NFS, UFS, SUN RPC, DHCP, DNS, NIS
What this document is not:
It is not a network administration tutorial.
It is not a JavaStation installation guide.
It is not about configuring Solaris, or Netra J.
It is instead a troubleshooting guide.
It assumes you already have a Solaris server and a JavaStation,
have tried to follow the instructions but have run into problems.
If you do not have system administration skills, this document will
probably be beyond you, and you should give it to your system/network
administrator for them to do the installation.
Facts to remember:
1) The JavaStation has only one hardwired persistent parameter - its ethernet
address. EVERYTHING else is from the net - mostly from the boot server.
2) The Solaris boot server can look up things like hosts, usernames, etc.
from several locations.
You may look at the /etc/hosts file, and think it's fine, but there
is a very important file - /etc/nsswitch.conf - which tells the server
if it should look in local files at all, or instead should use DNS,
NIS (yellow pages), or NIS Plus or several of these.
3) The boot server and the JavaStation do not necessarily get their
information from the same place. So if you want to test to see if
a host is known in DNS, what the JavaStation finds and what the server
finds may be different.
Specifically :-
The JavaStation looks up hosts ITSELF, it does not ask the server
to do this. So saying that something works on the server is not enough.
The boot server only tells the JavaStation where to go to ask the question.
This is based on the information you typed into jdhostmgr.
4) You have some very useful diagnostic tools, discussed in a separate
document. Briefy, these are (in order of usefulness) snoop, trusss, tip,
and snmptrapd. Also some of the DHCP admin commands can tell you if
that is working properly.
Overview
First a brief overview of how a JavaStation 1 boots.
The JavaStation when switched on, self tests and then broadcasts for
information about itself. This information must have been configured
on a server.
That server responds to requests from the JavaStation to download
its operating system (JavaOS).
Once that has been downloaded the JavaOS can start running, configure
itself, and put up a login screen so users can login to it.
That is a VERY high level view, and we will go into each of
the stages in lots of detail.
A note on HotJava Views: everything you see here applies to HotJava Views.
The only differences in its booting process are:
1) The JavaOS image loaded has extra embedded functionality.
2) DHCP needs to be configured to return an extra piece of information:
an HTTP URL which is the location of a configuration file.
What do you see when you switch on a JavaStation on a properly configured
network?
(Note the terminology about properly configured network -
it is important to remember that what you are
configuring is the boot server and network services - no configuration
is done on the JavaStation itself)
The following is based on a JavaStation 1 PROM level 2.30 loading
JavaOS 1.0 LAR (Limited Access Release):
1) The screen is black while hardware self tests are done.
2) The screen goes white and the logo and a couple of lines of
information such as ethernet address and PROM revision level appear.
3) After a short while (30 seconds) a raster of a brewing cup of coffee
appears with the message "JavaStation now brewing". This is known as
the "happy boot" image for some reason.
4) Shortly after that a starry screen saver appears.
5) Shortly after that a log in box appears.
It should now be possible to at least log in as "guest"
(NB guest login has been removed in the JavaOS 1.0.1 release).
6) If users' login names and home directories are properly configured
on the NIS (YP) server, it should also be possible to login as a user
and access their home directories (more on this later).
I will refer to each of these visible stages occasionally as VSn -
i.e., VS2 is when the screen displays ethernet address.
What is happening at each of these stages?
VS1
---
VS1 is internal. If the JavaStation does not pass this point,
you have a hardware problem.
Make sure all peripheral devices are properly plugged in.
If you added any 3rd party memory, remove it.
VS2
---
The JavaStation downloads a boot strap kernel, and then a raster
image which it displays in the next stage.
VS3
---
VS3 is when the JavaStation is downloading and
booting up the JavaOS.
VS4
---
The JavaOS is requesting configuration information via DHCP protocol.
VS5
---
We have a DHCP reply and the JavaStation is now fully booted.
VS6
---
Not really different than VS5, but whether this works depends
on NIS and other services being properly configured.
Boot Sequence for JavaStation 1 and JavaOS 1.0.X
Who Issues Protocol Broadcast? Who answers What is supplied
JavaStation Rarpd on boot
OBP RARP Yes server pre-assigned IP address
JavaStation tftpd on boot
OBP TFTP No server inetboot executable
inetboot RARP Yes Rarpd on boot pre-assigned IP address
server
inetboot BPARAM Yes boot server path to javaos/kona wad
on boot server
"happy boot" .ras file,
inetboot NFS No boot server javaos/kona/ wad image
(JavaOS,
HotJava/HotJava Views)
DHCP server,
JavaOS DHCP Yes prob. on boot DHCP parameters
server
JavaOS NIS No NIS/YP server yppasswd and auto.home
entries
JavaOS DNS No DNS server IP address of home dir
NFS server
JavaOS RPC No home dir NFS NFS filesystem handle
server
Physical Network Connection Problems
The JavaStation 1 has no disk or locally stored O/S.
Thus it must boot from the network.
There is *nothing* a user can configure, so there's nothing a user
can misconfigure! So if the hardware is fine, the problem is elsewhere.
On entry to VS2 the JavaStation will complain if it is not
connected to an ethernet.
If this happens, check your ethernet cable and hub.
If necessary, plug in a different (kind of) computer to the same cable
and jack as you were using for the JavaStation and see if it can
successfully communicate.
If that works fine, maybe the JavaStation has a hardware problem on
its ethernet interface, but experience says this is unlikely and the cables
or hub are more likely to be the problem. Such a problem should be caught by
the self-test at power-on. For example, it may complain about failing the
internal loopback self test. In this case a replacement JavaStation is needed.
If you see CRC framing error messages, that almost certainly means
you have substandard cabling.
The start of the network booting process
The JavaStation 1 has a PROM essentially the same as that in all
Sun workstations.
That PROM can network boot in only one way.
It broadcasts a RARP query to find its IP address, then it
contacts the host which responded again, this time using TFTP,
asking it it for a bootstrap kernel (inetboot.jd).
RARP and TFTP are both standard protocols.
RARP = Reverse Address Resolution Procotol.
TFTP = Trivial File Transfer Protocol
RARP broadcast troubleshooting
Broadcast means that an (ethernet) packet with all 1's in the destination
address is sent out.
However its source ethernet address *is* filled in - since the
hardware knows its own ethernet address and to do otherwise would
be illegal ethernet protocol. That would be having no or an incorrect
return address, so there could be no reply!
Note that TCP/IP protocol packets are "wrapped up" inside ethernet packets
when transmitted over an ethernet.
This RARP packet will also be all 1's in the destination IP address.
Since the JavaStation has no idea of its IP address at
this time, its source IP address is not filled in.
Here we see a broadcast, and a little later the reply.
7 1.02082 BROADCAST -> (broadcast) RARP C Who is 8:0:20:7c:b8:8a ?
10 0.00291 jakarta -> krupps RARP R 8:0:20:7c:b8:8a is 129.145.22.
82, krupps
So this succeeded.
Q. What if I do not see the broadcast?
A. This means you are probably not on the same subnet!
The broadcast is not being allowed throught the routers.
Customer will have to put his JavaStation on the same subnet.
[[[ Note:
There are some circumstances in which this will work across
subnets, but will later fail.
For example, routers can be configured to pass certain types of
broadcast packets, and RARP is a common one to allow.
In this configuration you will likely fail at the bootparams stage (later).
]]]
[[[ Note:
Also seeing the correct ethernet address of the JavaStation does not 100%
prove you are on the same subnet. This was a surprise to me first time I
saw it.
Normally a packet will acquire the ethernet source address of the router
which sent it, just as if that were a host.
This way the reply will be addressed to the same MAC (ethernet) address
and the standard ethernet interface implementations will know to pick
up that packet, and will examine the IP contents and forward the IP
packet appropriately.
However, some CISCO routers will package up the entire ethernet frame
as opposed to just the TCP/IP packet, to pass it over an FDDI backbone
for example.
]]]
[[[ Note:
One consequence of not having the source IP address filled in is
that if you "snoop" for packets to or from the JavaStation as in
"/usr/sbin/snoop mrcoffee" for a JavaStation called mrcoffee, you will
not see this broadcast.
So snoop should either be an unqualified snoop or should specify
the ethernet of the JavaStation, not the IP address or hostname.
So if your JavaStation reaches VS2, does not complain about
not having an ethernet, but you see nothing in the snoop trace,
you might want to check using snoop with no parameters.
What this might show you is that you have, for instance, given the
wrong IP address to the JavaStation.
i.e. you are snooping for mrcoffee, IP address 198.3.4.5, but
somehow the IP address being given to your JavaStation is different,
then you will never see any ethernet traffic for the JavaStation since
you are looking for the wrong thing.
This might happen for a variety of reasons, all are misconfigurations.
For example, the "snoop" command finds out the IP address to watch
for by doing a lookup which might go to a different naming service
such as DNS which is wrongly configured.
]]]
Q. What it I see the broadcast but no reply?
A. You probably have a problem on the server you expect to reply!
On a Solaris system, the process that replies is /usr/sbin/in.rarpd .
It is started by inetd, based on the entry in /etc/inetd.conf .
The "hosts" line in your /etc/nsswitch.conf file shows the places
searched for ether to host mappings and in which order.
Local /etc/ethers file is what you probably should be using.
You can run rarpd in debug mode (-d option) if you want to be sure:
- kill the existing rarpd processes (there will be at least 2)
- run "/usr/sbin/in.rarpd -a -d"
- power on the JavaStation
- you should then see something like :-
/usr/sbin/in.rarpd: device le ethernetaddress 8:0:20:7c:8c:96
/usr/sbin/in.rarpd: device le address 129.145.22.90
/usr/sbin/in.rarpd: device le subnet mask 255.255.255.0
/usr/sbin/in.rarpd: starting rarp service on device le address 129.145.22.90
/usr/sbin/in.rarpd: RARP_REQUEST for 8:0:20:7c:b8:8a
/usr/sbin/in.rarpd: good lookup, maps to 129.145.22.82
/usr/sbin/in.rarpd: immediate reply sent
/usr/sbin/in.rarpd: RARP_REQUEST for 8:0:20:7c:b8:8a
/usr/sbin/in.rarpd: good lookup, maps to 129.145.22.82
/usr/sbin/in.rarpd: immediate reply sent
If you do not see this, then check the ethernet address carefully against
what is in /etc/ethers or whatever map you are using.
TFTP - loading inetboot
Having read the RARP reply, the JavaStation sends a TFTP Read
request to the host which sent the reply.
Success mode
The response should be about 300 512-byte reads (to read the 150K image),
each matched with an acknowledgement of the read :
22 0.15637 jakarta -> krupps TFTP Data block 1 (512 bytes)
23 0.00272 krupps -> jakarta TFTP Ack block 1
24 0.00063 jakarta -> krupps TFTP Data block 2 (512 bytes)
25 0.00266 krupps -> jakarta TFTP Ack block 2
...
...
632 0.00786 jakarta -> krupps TFTP Data block 303 (512 bytes)
633 0.00264 krupps -> jakarta TFTP Ack block 303
634 0.00055 jakarta -> krupps TFTP Data block 304 (152 bytes) (last
block)
635 0.00192 krupps -> jakarta TFTP Ack block 304
Failure modes
If the host server's TFTP software does not know anything about the
JavaStation, it will send an access violation reply.
The Javastation will then resend the read as a broadcast.
This will also most likely generate failure messages:
krupps -> jakarta TFTP Read "81911652.SUN4M" (octet)
jakarta -> krupps TFTP Error: access violation
krupps -> BROADCAST TFTP Read "81911652.SUN4M" (octet)
mo-betta -> krupps TFTP Error: file not found
jakarta -> krupps TFTP Error: access violation
valadez -> krupps TFTP Error: access violation
bassman -> krupps TFTP Error: access violation
Typically this means that the responding host does not have a file in
/tftpboot (or file pointed to by a link) which corresponds in name to
the IP address of the JavaStation.
If it gets a reply but the boot file (inetboot.jd) is corrupted, then the
JavaStation will print a message on its screen :
"The file to boot may not be present"
and then hang.
To fix :-
make sure in.tftpd can be started with the information in /etc/inet.conf
make sure the IP address is OK
make sure the inetboot.jd is OK
Loading the JavaOS Kernel
There are a lot of steps here.
Here is a summary of what should happen:
+ boot inetboot.jd
+ issue RARP request to find IP address
+ issue BPARAM request to find simple hostname
+ issue BPARAM request to find NFS location of kernel
+ NFS mount this location
+ NFS read image.ras from kernel location
+ display this raster
+ NFS read kona (JavaOS image)
+ boot JavaOS
RARP again
Now inetboot.jd has been loaded, the boot PROM code hands over/yields
to inetboot which starts running.
inetboot.jd has no access to the information provided to the boot PROM
code, and so the information about the IP address of the JavaStation has
been lost.
It again uses RARP to find this.
This is why you will see an ARP reply again.
If you have reached this point, this SHOULD work, since it was needed
to get this far!
But for the sake of completeness, if you do a snoop on the ethernet address,
here is what you will see:-
636 0.61242 OLD-BROADCAST -> (broadcast) RARP C Who is 8:0:20:7c:b8:8a ?
641 0.00251 jakarta -> krupps RARP R 8:0:20:7c:b8:8a is 129.145.22.
82, krupps
BPARAM
inetboot.jd is just a bootstrap kernel which knows how to use a few
other protocols: BPARAM and NFS
It uses BPARAM to locate JavaOS and NFS to read it from the server.
First it sends a broadcast BPARAM packet, supplying the IP address which it
obtained from the RARP reply and asking for its hostname back.
610 0.62002 krupps -> 129.145.255.255 BPARAM C WHOAMI? 129.145.22.82
611 0.02582 jakarta -> krupps BPARAM R WHOAMI? krupps in support.Co
rp.Sun.COM
Next it then asks for a file "root".
This file is the name of an attribute in the /etc/bootparams file
for this host (krupps).
# more /etc/bootparams
krupps root=jakarta:/export/root/JavaDesktop boottype=:js
The value is returned as the reply:
613 0.00362 krupps -> jakarta BPARAM C GETFILE root
614 0.00201 jakarta -> krupps BPARAM R GETFILE File=/export/root/Ja
vaDesktop
Having received this reply, we are now done with BPARAM and can proceed to NFS.
Troubleshooting BPARAM
Q. I see a BPARAM WHOAMI, but no reply?
A. First make sure the server and the JavaStation are on the same subnet.
As previously mentioned, some networks are set up to allow forwarding
of RARP broadcasts, but few allow BPARAM broadcasts.
If that checks out, the server is likely misconfigured.
A daemon "/usr/sbin/rpc.bootparamd" replies to the BPARAM requests.
It is an rpc daemon.
It is listed in /etc/rpc :
bootparam 100026
But it is started only in /etc/init.d/nfs.server at boot time
so long as /tftpboot exists.
It forks a child to service each BPARAM request.
This child must read from /etc/bootparams .
To make sure this file is consulted, make sure "files" is first
on the line in /etc/nsswitch.conf
# grep bootparam /etc/nsswitch.conf
bootparams: files nis [NOTFOUND=return] files
If bootparamd is having problems you can restart it :
sh /etc/init.d/nfs.server stop
sh /etc/init.d/nfs.server start
Also look in the file itself.
Does the name in there match what The JavaStation is looking for?
For instance, it is important to name the JavaStation without
the full DNS domain name.
E.g., if you named your JavaStation "krupps.corp.sun.com" at install time
but bootparams will only know about "krupps", so this will fail.
[[ Note:
The knowledgeable among you may be asking, if it is an rpc daemon,
shouldn't we first see a request to rpcbind to find the port on which
rpc.bootparamd is really listening?
The answer is that in fact it is the rpcbind port (111) that is used,
but inside the packet is an indirect RPC request.
This means that rpcbind forwards the request itself to rpc.bootparamd
and returns the result to the caller.
]]
NFS - downloading JavaOS
NFS is the Network File System - an industry standard invented
by Sun. It makes it easy to access filesystems on other computers.
There are two stages in accessing a file by NFS:
1) Mounting the remote filesystem
2) Looking up the file.
Mounting the file system
As a result of the BPARAM query, we have the NFS location
of the JavaOS kernel jakarta:/export/root/JavaDesktop .
A snoop of a successful mount will look like this:
615 0.00284 krupps -> jakarta PORTMAP C GETPORT prog=100005 (MOUNT)
vers=1 proto=UDP
616 0.00220 jakarta -> krupps PORTMAP R GETPORT port=32818
617 0.00271 krupps -> jakarta MOUNT1 C Mount /export/root/JavaDeskt
op
618 0.00810 jakarta -> krupps MOUNT1 R Mount OK FH=970E
The PORTMAP request is a call to the portmapper on the server, to
ask the server for the address of the RPC program "mountd".
Originally portmapper was a separate program but it is now built
in to /usr/sbin/rpcbind, however the protocol is unchanged.
Having obtained the address of mountd, inetboot.jd issues the mount
request.
If /usr/lib/nfs/mountd is running then the successful mount reply
above should be returned.
Troubleshooting
The value jakarta:/export/root/JavaDesktop
means JavaOS can be found in a directory /export/root/JavaDesktop on
a host called jakarta.
This directory must be accessible to other hosts.
The terminology is to say it is "shared".
You can check this by going to the server and typing "share":
# share
- /export root=tacitus:babylon5:migkiller.east ""
This shows that /export is shared. This means all subdirectories
are also shared.
The jdhostmgr or NetraJ should take care of this for you.
Be wary of anything on the line like "rw=admin-hosts"
since it means only these hosts (admin-hosts) can mount the filesystem.
Looking up and Reading the happy boot image file
This is not critical: if this fails JavaOS will continue:
image.ras is just a pretty picture to keep you amused while the
much larger kernel is loaded.
(I can't think of any reason why you can't customize this image)
624 0.09445 krupps -> jakarta NFS C LOOKUP2 FH=970E image.ras
625 0.00127 jakarta -> krupps NFS R LOOKUP2 OK FH=649C
626 0.00582 krupps -> jakarta NFS C READ2 FH=649C at 0 for 32
627 0.00089 jakarta -> krupps NFS R READ2 OK (32 bytes)
628 0.53978 krupps -> jakarta NFS C READ2 FH=649C at 32 for 8192
629 0.00251 jakarta -> krupps NFS R READ2 OK (8192 bytes)
etc ...
Looking up and Reading the Java OS file
JavaOS "knows" that its kernel is called "kona", so in the location it mounted
it issues a read request for a file called "kona".
This file is about 5Mbytes and it takes a few seconds and over 3,000
IP packets to pull it over.
619 0.00608 krupps -> jakarta NFS C LOOKUP2 FH=970E kona
620 0.00088 jakarta -> krupps NFS R LOOKUP2 OK FH=48BE
621 0.00400 krupps -> jakarta NFS C READ2 FH=48BE at 0 for 52
622 0.00077 jakarta -> krupps NFS R READ2 OK (52 bytes)
623 0.00420 krupps -> jakarta NFS C READ2 FH=48BE at 52 for 64
624 0.00099 jakarta -> krupps NFS R READ2 OK (64 bytes)
625 0.35258 krupps -> jakarta NFS C READ2 FH=48BE at 65536 for 8192
626 0.00163 jakarta -> krupps NFS R READ2 OK (8192 bytes)
...
...
760 0.00015 jakarta -> krupps UDP continuation ID=36918
3761 0.00014 jakarta -> krupps UDP continuation ID=36918
3762 0.00013 jakarta -> krupps UDP continuation ID=36918
3763 0.03957 krupps -> jakarta NFS C READ2 FH=48BE at 3743744 for 1
148
3764 0.00090 jakarta -> krupps NFS R READ2 OK (1148 bytes)
At this point JavaOS is ready to boot.
Any failure at this point is likely down to a missing or corrupted
"kona" file on the server.
Booting JavaOS
Once again a new image starts running - this is the final one:
JavaOS or kona.
It starts running, finds its screen and puts up the starry background.
This is VS3/VS4 referred to near the beginning of the document.
However once again the JavaStation has lost its memory and needs
to rediscover its IP address.
This time it does not use RARP - it uses DHCP protocol.
So if DHCP can supply IP address, why are we using RARP at all?
The answer is that the PROM in the Javastation is basically a regular
Openboot PROM, and does not have DHCP protocol built in, so it can't
do it. Future revisions of the Javastation may have this ability, thus
simplifying the boot process. In fact, future versions will likely store the
JavaOS in flash PROM too.
Note, also inetboot does not know DHCP.
DHCP - getting JavaOS configuration
DHCP is new in Solaris 2.5.1 ISS (Internet Server Supplement)
and will be bundled in Solaris 2.6.
A misconception is that DHCP (which stands for Dynamic Host Configuration
Protocol) is for dynamically allocating IP addresses from a pool.
This is only one of the pieces of information that can be supplied and
it is NOT used by the JavaStation server software.
IP addresses are statically allocated.
This is important since the other protocols such BPARAM used earlier
had to know the IP address.
One common mistake is to run dhcpconfig yourself either because
you want to or you think you must. This causes problems.
Unless you want problems, don't do this.
jdhostmgr or NetraJ will do everything for you.
A snoop of a successful DHCP request will look like this:
3765 22.79636 jakarta -> krupps DHCP/BOOTP BOOTREPLY
3766 0.08125 jakarta -> krupps DHCP/BOOTP BOOTREPLY
Notice again that the broadcast request ASKING for an IP address does not
show up in the hostname qualified snoop.
Here is another snoop showing the request too:
4084 0.02237 OLD-BROADCAST -> BROADCAST DHCP/BOOTP BOOTREQUEST
4085 0.01513 jakarta -> (broadcast) ARP C Who is 129.145.22.82, krupps ?
4086 0.93146 jakarta -> (broadcast) ARP C Who is 129.145.22.82, krupps ?
4093 0.68782 jakarta -> (broadcast) ARP C Who is 129.145.22.82, krupps ?
4094 0.12172 jakarta -> krupps DHCP/BOOTP BOOTREPLY
4095 0.01813 OLD-BROADCAST -> BROADCAST DHCP/BOOTP BOOTREQUEST
4096 0.08438 jakarta -> krupps DHCP/BOOTP BOOTREPLY
This reply tells the JavaStation:
*) IP address
*) hostname
*) IP netmask
*) router (gateway) IP address
*) DNS domain name
*) DNS server name
*) NIS (YP) domain name
*) Time zone
The first two are unique to that JavaStation.
DHCP reads this from /var/dhcp/NNN_NNN_NNN_0 using the ethernet
address a key. NNN_NNN_NNN_0 is a subnet number such as 129_145_22_0 .
The others are common to all JavaStations booted from this server.
DHCP reads this from /var/dhcp/dhcptab .
These values were based on what was detected from the server, and
what you typed into jdhostmgr.
As a rule of thumb, if you didn't get asked to type it in, it's probably
using the same value as the server.
For example, the time zone will be the same as the server's time zone.
If all goes well here, the login prompt will appear on the JavaStation.
Trouble-shooting DHCP
To check your DHCP set up run the command:
dhtadm -P
This is just an inquiry command.
# dhtadm -P
Name Type Value
==================================================
SUNW.JavaStation Macro :LeaseTim=-1:Timeserv=129.145.22.90:DNSdmain=corp.sun.com:DNSserv=129.145.1.8:Subnet=255.255.255.0:JOScmd1="+tz PST8PDT7,97/3:00:00,300/1:00:00":NISdmain=support.Corp.Sun.COM:Router=129.145.22.50:JOScmd2="+console +url http://jakarta.corp/jdt/props/selector.init":
JOScmd4 Symbol Vendor=SUNW.JavaStation,104,ASCII,1,0
JOScmd3 Symbol Vendor=SUNW.JavaStation,103,ASCII,1,0
JOScmd2 Symbol Vendor=SUNW.JavaStation,102,ASCII,1,0
JOScmd1 Symbol Vendor=SUNW.JavaStation,101,ASCII,1,0
#
[[[ Note:
in here the String
"JOScmd2="+console +url http://jakarta.corp/jdt/props/selector.init"
indicates we are configured for HotJava Views.
]]]
Do not run any dhcp configuration commands directly.
Unless you are serving other devices by DHCP from your Solaris server,
this is unnecessary and extremely ill-advised since this can cause conflicts
with the jdhostmgr configuration.
Important files:
/etc/default/dhcp
This file tells the dhcp daemon where to find its configuration.
If you lose this file or have its contents incorrect, dhcp will
of course not be able to function.
SUNWjdse provides a version of this file which points to /var/dhcp .
The original version is installed by SUNWjdse as
/opt/SUNWjdse/lib/etc.default.dhcp .
If /etc/default/dhcp is not the same as this file, you most likely
ran dhcpconfig directly!
Restore this file if it is incorrect.
/var/dchp/ has two important files:
dhcptab : which has the information DHCP will provide to clients
(see above)
NNN_NNN_NNN_0: this is a file named affter your subnet (eg 129_145_22_0)
and contains lines which have (amongst other things):
* ethernet of device to serve
* hostname of device to server
* IP address of device to serve
* IP address of server
These files are created by jdhostmgr.
The 1st when you "set defaults",
the 2nd when you "add host" - i.e., add a JavaStation.
If these files get corrupted, then:
1) make sure /etc/default/dhcp is correct
2) start jdhostmgr
3) remove all javastations
4) exit jdhostmgr
4) remove all files in /var/dhcp
5) start jdhostmgr
5) re-apply the defaults
6) re-add the Javastations
7) save changes and exit
You do not need to reboot the server.
Again, use snoop if all else fails.
If you do not see a DHCP/BOOTP BOOTREPLY look again at your server
config.
If you see several from different hosts you may have a DHCP conflict.
There is a known problem with NT server's DHCP.
JavaStation may have problems co-existing on the same subnet with
such an NT server.
The NT server generates an illegal reply which prevents the JavaStation
from receiving the correct reply from the Solaris server.
Other DHCP problem causes:
* Duplicate IP address. You should see error messages on the
server console.
The flags field in the network file /var/dhcp/NNN_NNN_NNN_0 will
probably be 07 rather than the correct 03. 07 means the UNUSABLE bit
is set. Run "pntadm -Pv NNN.NNN.NNN.0" supplying your subnet to see
the format output - if flags are "PMU" you have a problem - the "U" means
unusable. Sometimes manually fixing this by changing the "07" to "03" will
suffice if the cause of the problem no longer exists. Do check to make
sure the IP address is not otherwise in use if you see this problem.
* Inconsistent DHCP address. jdhostmgr does not configure dhcp (now).
If dhcp gives your JavaStation an IP address different from
that setup by jdhostmgr you will be seeing stars.
Of course, you can ping your JavaStation, provided you use
the /etc/hosts IP address. Snoop will show the Netra-J
ANSWERING the JavaStation DHCP request.
Don't expect to see any error messages on the server console.
* DHCP out of IP addresses. This error displays on the console.
In this case the JavaStation will continue to retry the
DHCP request forever (timeout), and the server will not answer.
Typically this means you configured the block of Ip addresses to be
dynamically allocated - JavaStations need static allocation.
* IP mystery on Netra J. In this case the Netra J DHCP is responding with what
is thought to be the correct JavaStation IP address. Rebooting
the server and/or the JavaStation seems to clear this class of problems.
Trouble-shooting non-DHCP issues
What I mean by this is that DHCP funtioned, but the information
you provided it was wrong.
This is not believed to prevent you from getting the login prompt,
but may prevent you from proceeding much beyond that.
The most typical problems are:
1) A non-standard subnet mask (must be 8 bits)
2) A router (gateway) which is not reachable (not on the same subnet)
3) A DNS server which is not reachable or which is not configured
with host information for the JavaStation and its server.
NIS and DNS - Logging in to the JavaStation
If available, Login as guest.
[[ NOTE: This feature has been removed in JavaOS 1.0.1 and later releases,
as opinion was that this was a security issue. If you do not see a "guest"
button on the login screen you are running JavaOS 1.0.1 or later.]]
At this point you should be able to log in as "guest" via the guest button.
This is a built-in user which allows you to bring up the HotJava
browser and bring up HTML pages and applets.
The user is not authenticated and has no home directory so cannot
save preferences.
Or, Login as yourself.
When you login, JavaOS uses NIS (YP or yellow pages) to find a passwd
file entry for you.
This is exactly the same as SunOS 4.x workstations and even many
Solaris workstations which use a network name service.
So if you already have a Sun network this may be an easy step.
It also uses NIS to find your home directory in the NIS auto.home map.
NetraJ will help you set up NIS if you need to.
If you don't have NetraJ or NIS you can obtain NIS Kit 1.2 (an unbundled
product). And Solaris 2.6 should include this functionality as standard.
If you are running NISPlus (NIS+) you can run it in YP emulation mode by
uncommenting the line:
# /usr/sbin/rpc.nisd $EMULYP
in /etc/init.d/rpc
and running:
# sh /etc/init.d/rpc stop
# sh /etc/init.d/rpc start
You may also need to remove the requirement for NIS+ authentication
in order to access the maps. From SRDB 7340:
The nis+ server running in compatibility mode, does not have read
permissions for others set. Type nischmod n+r passwd.org_dir on the
nis+ root master as root, to allow nis or nis+ clients that are not
authenticated to read the passwd entry.
You may need to do the same for auto_home.org_dir
Here is a successful login :-
snoop -i snoop.log -p3,20
1 0.00000 krupps -> nasc-enet-22 NIS C MATCH philr in passwd.byname
2 0.00371 nasc-enet-22 -> krupps NIS R MATCH OK
3 0.00995 krupps -> nasc-enet-22 NIS C MATCH philr in auto.home
4 0.00316 nasc-enet-22 -> krupps NIS R MATCH OK
5 0.01530 krupps -> sun-barr.EBay.Sun.COM DNS C port=1024
6 0.03987 sun-barr.EBay.Sun.COM -> krupps DNS R port=1024
7 0.01010 krupps -> rainbow PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP
8 0.00389 rainbow -> krupps PORTMAP R GETPORT port=32840
9 0.00696 krupps -> rainbow MOUNT1 C Mount /export/home6/philr
10 0.00878 rainbow -> krupps MOUNT1 R Mount OK FH=9B12
11 2.50153 krupps -> rainbow NFS C LOOKUP2 FH=9B12 .
12 0.00178 rainbow -> krupps NFS R LOOKUP2 OK FH=9B12
13 0.00335 krupps -> rainbow NFS C LOOKUP2 FH=9B12 .hotjava
14 0.00169 rainbow -> krupps NFS R LOOKUP2 OK FH=773C
15 0.00312 krupps -> rainbow NFS C LOOKUP2 FH=773C properties
16 0.00212 rainbow -> krupps NFS R LOOKUP2 OK FH=14F0
Here is a packet by packet account (first column is packet #)
1,2 It finds the username in yp (NIS) passwd MAP
3,4 It finds the home directory in yp auto.home map
5,6 It looks up the IP address of the home directory server
7,8 It contacts the portmapper to lookup rpc port of mountd
9,10 It contacts the mountd on the home directory server and does the mount
11,12 It looks up "." relative to the mount point it requested
13,14 It looks up ".hotjava" relative the last handle it received
15,16 It looks up "properties" relative the last handle it received
Trouble-shooting NIS
Is NIS working at all?
On your server type "domainaname"
- this should echo you YP domain
if it does not enter your YP domainname into /etc/defaultdomain and reboot
On your server type "ypwhich"
this should tell you the name of your YP server.
If it does not, and instead says not bound, then the JavaStation will
have the same problem. Fix your YP server and then retry logging in
to the JavaStation.
Saving preferences in HotJava
Perhaps you can log in but when you try to save preferences you get
Can't save Properties to ./hotjava/properties
There are a number of possible reasons for this problem.
This document should be useful in resolving the problem
whether your JavaStation is managed by a NetraJ installation
or a regular Solaris installation with the SUNWjdse and DHCP packages.
The most likely root cause is that the user's home directory is most likely
not accessible.
We will go through the possible causes of this and other problems.
Things to check:
1) Is your home directory correct in the automounter maps?
ypcat -k auto.home should show for a user philr whose home
directory is on /export/home on the server jakarta
philr -rw,intr jakarta:/export/home/philr
IF this does NOT appear, then you need to go to the YP master, and
edit /etc/auto_home, and add a line exactly like the above.
Then
# cd /var/yp
# /usr/ccs/bin/make
you should see (amongst other stuff)
... updating auto.home ....
... pushing auto.home ....
and the ypcat command should now work.
2) Is the filesystem properly shared?
This file system should be exported
i.e "share" should show something like
- /export/home rw ""
3) Is it shared, but not to the JavaStation?
If share showed that any host or netgroup restrictions applied to the share
such as
- /export/home rw=client1:netgroup1 ""
then you must ensure the JavaStation is included in this netgroup.
4) Can any filesystem be mounted from the server by any system?
make sure rpc.mountd is running on the server
# ps -ef|grep nfs/mountd | grep -v grep
root 358 1 0 Nov 24 ? 1:14 /usr/lib/nfs/mountd
5) Can we resolve the hostname that is mentioned in the auto.home map?
This is one of the more perplexing and mysterious problems, that can
be particularly confusing if the boot server and home directory server
are the same host, since it is not intuitive that the JavaStation can't
find the host from which it booted.
But the cause should be understood from the following.
The auto.home map will return a line like:-
philr -rw,intr jakarta:/export/home/philr
The JavaStation now that its booted use DNS to look up IP addresses from
hostnames.
Make sure the server identified in the auto.home map (jakarta in this case)
is in the DNS maps being consulted by the JavaStation
It is expected that the JavaStation and the user's home directory are
in the same DNS domain, so the following should be valid
* look at /var/dhcp/dhcptab and verify what the value of DNSdmain is
look at /var/dhcp/dhcptab and verify what the value of DNSserv is
You can examine the DHCP table on the boot server for the JavaStation
with the command "dhtadm -P"
here is part of one /var/dhcp/dhcptab
SUNW.JavaStation m :LeaseTim=-1:Timeserv=129.145.22.90:DNSdmain=cor
p.sun.com:DNSserv=129.150.254.2:Subnet=255.255.255.0:JOScmd1="+tz PST8PDT7,97/3:
00:00,300/1:00:00":NISdmain=support.Corp.Sun.COM:Router=129.145.22.50:
Here DNS domain is corp.sun.com, and DNS server is 129.150.254.2
on a system such as jakarta try
nslookup - 129.150.254.2
>jakarta
Server: sun-barr.EBay.Sun.COM
Address: 129.150.254.2
Name: jakarta.Corp.Sun.COM
Address: 129.145.22.90
This should replicate what the JavaStation is trying to do
If however the response is instead more like:-
*** sun-barr.EBay.Sun.COM can't find jakarta.corp.sun.com: Non-existent domain
Then your problem is that the home directory server is not in the DNS
maps, so the JavaStaion can't look up its IP address, so can't begin
to mount your home directory!
This will have to be fixed by whoever administers your DNS server.
You should not need to reboot (anything) just log out and back in again,
although rebooting the JavaStation might be prudent.
6) Other (less likely) things to check
* that the autohome map correctly locates the user's home directory
* that their home directory and the .hotjava directory and the
.hotjava/properties file is owned and writable by them
7) If all this draws a blank, try a snoop!
Once the JavaStation has booted, then on the server, as root, type :-
# snoop -o snoop.log krupps
where krupps is the name of your JavaStation
Now log in to the JavaStation.
Note the packet count incrementing in snoop
Now try to save preferences in HotJava
Does the packet count go up again?
If yes, then JavaOS believes it can write, but for some reason
the file is inaccessible.
If it remains the same, then JavaOS did not manage to successfully
mount the file system with the user's home directory.
Compare your snoop with the successful login above.
NIS and DNS configuration
The Javastation uses the NIS and DNS network naming services.
Configuring these is beyond the scope of this document, which
is a trouble-shooting guide for booting JavaStations,
not a system and network administration tutorial.
However I will make a few points
If you have a NetraJ, then the Netra J will set up NIS and DNS
for you.
If however you are in a corporate intranet where these services
already exist, you will want to use their servers.
In that case you must ask your network administrators to make sure
that DNS knows about
1) The JavaStations
2) The boot server
3) The home directory server for all unix users who will login.
- the home directories must be NFS-mountable
DNS
Necessary for all host lookups.
Complex to set up and administer
If not using Netra J, refer to your system administrators
NIS
Easy to administer.
Superceded by NISPlus (see later)
Not bundled in Solaris 2.x (was in Solaris - SUnOS 4.x)
You need to buy NIS Kit 1.2
To initialise
1) Invent a domain name
This is different than DNS domain name, but it is usually sensible
to make it similar
eg DNS domain: corp.sun.com
NIS domain: javasupport.corp.sun.com
2) set the domainname to be current
domainname javasupport.corp.sun.com
3) put the domain name in /etc/defaultdomain to make it persisent
across reboots
`domainname` > /etc/defaultdomain
4) Initialise the server
ypinit -m
5) To rebuild maps after changes
cd /var/yp
/usr/ccs/bin/make
you can use ypwhich and ypcat commands to see if NIS is running
NISPlus
This is not needed BUT can be run in NIS compatibility mode.
If you already have NISPlus in your location, you may want to
ask your system administrators to run it in NIS compatibility mode
so the JavaStation can use it.
Here is what they need to know:-
If you are running NISPlus you can run it in YP emulation mode by
uncommenting the line
# /usr/sbin/rpc.nisd $EMULYP
in /etc/init.d/rpc
and running
# sh /etc/init.d/rpc stop
# sh /etc/init.d/rpc start
PRODUCT AREA: Hardware
PRODUCT: JavaStation 1
SUNOS RELEASE: n/a
HARDWARE: JavaStation 1