The order in which the protocols are used (from memory, I don't have a
sniffable sun handy anymore):
bootparams (yeah, it uses bootparams more than once)
Troubleshooting procedure with a standard sniffer (this is the easy way,
when it works) :
Start up a sniffer, like ethereal or snoop. Sniff on the
ethernet address if you want to see rarp packets too. If you don't
care about rarp packets, go ahead and sniff on the hostname.
Boot the sun diskless
Watch what comes up in the sniffer.
99 times out of a 100, the last thing exchanged between the sun
diskless client and the boot server is the thing you need to
troubleshoot. Then proceed as below for just that protocol.
The decaying usefulness of sniffers
Switches have made sniffers a lot less useful, as they only repeat
packets on "needed" interfaces. You can still see broadcast packets on
subnet, which is sometimes enough, sometimes not. Also, sometimes it
helps to start up a sniffer on the bootserver, as the two endpoints of
the conversation should see the packets they exchange.
ettercap is a sniffer that claims to be able to get around switches by
using arp poisoning, but it's never worked as advertised for me.
Finally, sometimes you can dig up an old hub (not a switch) and
insert the hub into the network above the diskless client, with a laptop
hung off the same hub. You can then sniff well from the laptop.
Without any sniffer at all next to the boot client
If the machine knows its IP address, it probably rarp'd
If the machine counts up in hex for a while, it probably tftp'd
at least some of what it needs. If it moves on to another step after
that (like the spinner), it's probably tftp'd fine.
If the machine knows a pathname to a root filesystem, it's
probably getting bootparams at least sometimes.
If you get kernel boot messages (like you would see if booting
from a harddisk), you're getting NFS.
Start up rarpd -d or in.rarpd -d. Boot the diskless client. If it says
nothing, the boot client and boot server aren't talking. If it outputs
errors, take a guess at what they mean and proceed accordingly. If you
have a sniffer, make sure the ethernet address sent in the rarp packet
matches the ethernet address you expected. If rarpd -d says it can't
find your host, check /etc/ethers, and check for duplicates in
/etc/ethers. It's easy to forward rarp through a cisco, at least to
cisco people. This is a broadcast.
Change inetd/xinetd to start up tftpd with the -l option. Boot the sun.
Then check syslog for messages. Sometimes I truss/strace/trace/par the
process to get errors without having to change inetd/xinetd (hint: tell
the syscall tracer to follow forks, and then trace inetd/xinetd. This
is better on a quiet system, and worse on a busy system. The option to
follow forks is usually -f). If you
have a sniffer, check if the filename being asked for is available on
the bootserver (and that it looks as expected. It should be the IP
address in hex, and then for older suns you should have ".karch"). If
you have sufficiently recent sun firmware, you can specify a tftp
server, see "help boot". With "the
workaround for the bpgetfile
problem" we use at UCI, this will be talking to autoinst.nacs.uci.edu,
not the on-subnet tftp server; for OS revisions without the workaround,
it should still try to use the on-subnet tftp server via broadcast.
It's easy to forward tftp through a cisco, at least to cisco people.
Start up rpc.bootparamd -d. If you see no output during a boot, then
the client and bootserver aren't talking. If you see output, interpret
the messages, and act accordingly. Some or all of this is done by
broadcast. It's hard to forward bootparams through a cisco. The cisco
doc claims it works, but an experienced cisco guy had a hard time
getting it to work.
Check syslog on the NFS server. Rerun sh -x /etc/dfs/dfstab. If you
have a sniffer, look for error messages there - sometimes it'll give a
useful error message as well as the path the client is erroneously
trying to get or identify what the client needs exported that wasn't.
You don't want to forward NFS thru a cisco. :)
Booting from the net with a nondefault adapter, with nondefault
negotiable network parameters:
The original questions was.. Can NIC settings (speed/duplex) be set in the
PROM before the OS is installed?
Yes it can be done. Thanks to ..
Clift, Robert T
ok> devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok> boot net
>>> boot net:speed=100,duplex=full - install
( http://www.sun.com/blueprints/0704/817-7526.pdf ) page 10 of 18.
Tue Mar 30 15:16:54 PST 2004 First draft, Dan Stromberg.