Good afternoon all,
Many thanks to those who took the time to respond thus far, I should
have mentioned in the first message that we did not have an RS-232 cable
that could connect to the CCU board and it was impossible for us to
monitor the boot process (we never had one for the SGI). Now, however,
we have one and when we boot the CCU, the following error arises:
whoami RPC call failed with Status 3
Panic vfs_mountroot: cannot mount root.
The troubleshooting manual suggests the bootparamd file is the source of
the error but this file is correct according to the manual. We are
trying a variety of approaches to solve the problem. If anyone has any
direct experience with the aforementioned errors, please advise.
Once again, thank you all for your responses. I will do a follow-up
post when this issue is resolved. The responses received thus far are
listed below.
Russ
Russ Hopson, Ph.D.
NMR Facility Supervisor
Brown University
Department of Chemistry, Box H
Providence, RI 02912
(o) - 401-863-3069
(b) - 401-235-8306
1.
How about running tcpdump to see what is going on? Just a thought.
2.
did you go through the steps described in chapter 9.3.4.2 in the
installation guide for linux 7.3. Following the boot process on through
the output of the console terminal of the CCU can pinpoint the problem
in 99% of the cases. Make sure the cable from the CCU to the serial port
of the workstation is in place.
Where does the boot process stop?
3.
we had a similar problem a year ago, and I accidentally figured out
what was wrong. The NMR Suite installation guide for LINUX recommends
hostname to be just "hostname." However, it should be
"hostname.domainame." (chapter 3.1 and 3.2)
4
if you have a terminal, attach it to the CCU to get more details.
Linux side I assume, that thr necessary demons are not running. Do the
following commands
ps -ef| grep boot
You should see /usr/sbin/rpc.bootparamd running
Then do
ps -ef| grep bfsd
You should see /usr/diskless/bfsd.linux
Next look for the output of
netstat -ia
If eth1 is available have a look for the output of
/sbin/ifconfig eth1
If you are interested, please feel free to post me the
results of all of the 4 commands.
On the other side there is a nice troubleshooting
guide from Jos van Boxtel and Michael Engelhardt
dealing exactly with your problem. Could be this
one, but I am not fully sure:
http://www.chem.wisc.edu/~cic/nmr/Guides/Bruker_AVANCE_manuals/The%20Interaction%20Between%20XwinNMR%20and%20UNIX%20(Aug%202001)%20-%20xwin-unix.pdf
5.
Sometimes telnet does not work properly, but that does not mean that the
computer is not communicating with the spectrometer. If you can
successfully ping, and "cd" to spect then the communications is probably
working. Try and run the spectrometer as is. I have had these issues
before on the Indystations. There is a way of connecting a cable off the
front of the CCU board to the computer that can monitor the CCU boot
process. I would suggest trying that to see what is really going on.
6.
We have one system running linux. We had Bruker do the LInux install
due to the numerous software errors that were encountered. Bruker used
a couple of different engineers to get it running. It took boards and
software fixes to resolve the upgrade issues. They did resolve the
problem quickly. Using xwin/windows and xwin/Irix was smooth and easy.
Linux was the tough one. Well worth the price of the service call to
get it resolved quickly without the headaches and frustration. Good
luck.
7.
I have almost no idea, but I appreciate your position so I'll think a
minute.
Sounds like the problem is Linux telnet. My first guess would be the
connection settings. When I was setting up terminal programs on the sparc,
there were some gruesome details. These programs used a modem (or null
modem) connection via RS232 ports, but there may be similar config files
for telnet so I'll mention them, despite the fact that they define
serial
connections, not TCP/IP:
The "cu" program required add a line into /etc/uucp/devices that
read: "direct cua/a -57600 direct".
The "tip" program required a line in /etc/remote that
read:
"porta:\par:dv=/dev/term/a:br#57699:el=^C^S^Q^U^D:ie%$:oe=^D"
Try another Linux box. (You can download a CD (www.knoppix.de) that will
boot any windows box into Linux (debian), without touching the Windows
installation (it loads into RAM - you should have 256 Mb for the GUI, use
runlevel 2 if less.)). If the default connection settings on another
Linux installation work, you can compare those to the Linux that Bruker supports.
Do remember to post the solution when you find it. After you auction it
back to Bruker.
8.
Is telnet function on your computer on? On the linux box, it may not be
installed or activated automatically. Can you telnet to other computer?
9.
Could it be a mistype in the license daemon? Have you put TCP- wrappers
on and generated a hosts.allow file that doesn't include the
spect? Sounds like you've tried everything hardware related. I'd like
to know your outcome. I hope to have to do this soon.
10.
Have you disabled the firewall on Linux workstation?
11.
At Louisiana State University we encountered a problem similar to the
one you are facing. In our case the system is a BRAND NEW AVANCE solid
state consol. The console was unpacked Wednesday of last week and the
next day both the HP Linux box and the CCU were FedExed to Billerica (By
the Bruker engineer) for them to solve the problem. Bruker asserts that
they some of the software had bee
corrupted and after they reinstalled XWINNMR all was fine. At any rate
when they shipped the computer and the CCU back the engineer now has the
system acquiring data.
12.
No direct experience, but did have trouble getting the sgi to
talk again after upgrading boards so that we can put a pc there. Not the
most robust connection. I imagine you've rebooted both and can telnet
to other computers. You might check to see if there are any firewall
settings on the second ethernet card. Does it say host not reachable?
which might indicate routing problems?
13.
Is it possible. that a restrictive firewall setting is getting in the
way? Can you telnet to any host (other than spect)? If not, perhaps
ipchains pr iptables are set up to block outgoing telnet? Try, as root,
"/sbin/service ipchains status" or "/sbin/service iptables
status". To disable those (for testing only!), "/sbin/service ipchains
off".
14.
Compare the netmasks on the SGI and Linux box. Odds are the Linux box
has a different netmask. Ping doesn't use the netmask but telnet does.
Received on Thu May 20 2004 - 19:17:01 MST