RE: AMMRL: Install of VNMRJ3.1 crashes X-server

From: hsin <hsin.wang_at_sci.ccny.cuny.edu>
Date: Tue, 15 Nov 2011 17:49:16 -0500

I would like to submit a summary on the post I submitted about a month ago on the X-server problem after VNMRJ3.1 install. I apologize for the tardiness. I have not been consistently working on the problem and in fact still am unclear what the real issue is. I can report that since the post I have requested static IP for a LINUX only machine (still CentOS 5.5). The initial install of VNMRJ3.1 lead to a blank screen like before, but I discovered that my school's DNS still had an old hostname for that IP. After clearing that up, I reinstalled VNMRJ. Before logging out my install account, I "ssh -X" into the vnmr1 account to launch vnmrj and use "vnmrj adm" to set up accounts. Despite that every time an account is created the terminal window displayed an error message: "X11 connection rejected because of wrong authentication", and that every time the vnmrj is launched there is a new .xsession-errors, the computer can be logged out and logged in without going to a blank screen.

I applied similar tactic to a virtual Linux machine on my office PC, which acquires its IP through DHCP. But the Speakeasy speed test website showed me that it always uses the same IP, and I verified that the IP is not given any hostname by my DNS. But after the install of VJ, and did all the remote "ssh -X" session with vnmr1 account, the screen went blank after I logged out of the install account.

So I am not clear whether I found the source of the problem. It is beyond my ability to make it work. So I have given up on it, even though I am unhappy about losing my ability to edit/compile pulse sequences or examine data on my office PC.

I wish to thank Rolf Kyburz, Eugenio Avarado, David VanderVelde, Dejian Ma, Eric Paulson, Chris Rithner, and Michael Strain for responding to my post. Their replies are included here at the end along with my original post. There are mainly two opinions: one is that the X configuration is altered by the VJ install, and the other is that it is an "identity crisis". I examined the xorg.conf files before and after the VJ install and found that it was not changed. There is more evidence of the "identity crisis", and in particular, the X11 authentication error. I wish I knew what kind of X11 authentication VJ has implemented, and whether that is reasonable. After all, there is no indication of any kind of failure in VJ install log. I was planning on the VJ upgrade on our spectrometer. I am not confident that I won't have a major headache with it. I am also weary of all the legacy linux software that is required by VJ install.

Hsin

== My original post

> I have a bizarre and frustrating case and I badly need help.
> Several months ago when I first received the VJ3.1, I installed it on a
> virtual machine running CentOS-5.5. It went well and everything seemed to
> work properly. That was a big help because it is much easier to manage
> spectrometers if you have something similar to look at right at your
> desktop in the office. Sometimes last month I modified the hostname, and
> the database did not work properly. After I talked with Agilent, I decided
> to reinstall VJ. It went without complaints. But as soon as I logged out
> of the installation account. The screen became blank (dark). It is not
> just X does not work. I could not switch between X and command line
> either. <CTRL><ALT><F2> (or <backspace>) etc has no response. I could
> remotely log in, but I do not know what else to do. So I had done the fresh
> install of OS almost 10 times. Sometimes CentOS-5.6, sometimes CentOS-5.5,
> and I could not find anything older on the web. I have tried both VMware
> and Virtual Box, with the same results. Everything seems to work perfectly
> until I installed VJ3.1 and log out. Then everything is blank. In my
> hands, in CentOS-5.6 or newer, the VJ install also fails to put the vnmrj
> related lines in /etc/sudoers. I talked to Eugenio Alvarado several times.
> He has quite a lot of experience with VJ install in various linux systems,
> but he does not see what I see. The latest is that I got another
> stand-alone PC just for CentOS install and I did several times again. One
> time I got all the X software available from the distribution, another time
> just gnome desktop plus development libraries and tools (plus VJ required
> packages), yet another time with the deactivation of the network. None of
> these made any difference. Everything is well until VJ is installed and
> logged out. I should add all of these tries are with DHCP and I am also
> behind a router. I am very puzzled how the install of one software can mess
> up the display. And I could not get it to work like the first time several
> months ago. Since I can login remotely, I would appreciate if someone
> could help me reset the display remotely. --
> Hsin Wang, Ph. D.
> NMR Facility Manager
> City College of New York, CUNY
> Marshak-1217
> 160 Convent Ave.
> New York, NY 10031
> 212-650-5831 (phone)
> 212-650-8719 (fax)

== some of the input I received. I did try commenting out the 2 lines with visudo without success.
I can't give you direct help related to the use of CentOS -
simply because I do not have the resources to try this out. I mainly wanted
to give you one pointer: In the old RHEL 5.1 kickstart script that we
distributed with our installation DVD a while ago, there's one modification
which may be worthwhile checking for: if (as root) you call "visudo"
or "/usr/sbin/visudo" and make sure the lines
        Defaults requiretty
and
        Defaults env_reset
are *commented out* (insert a "#" as first character), then install VnmrJ. If
VnmrJ is installed already, you can still do the above modification, then (as
root) call
        /vnmr/bin/sudoins
and finally (as vnmr1) call
        /vnmr/bin/dbsetup
which should get the database to work. Even though this is CentOS, you could
still try downloading, installing and running "bin/sysprofiler" from the
on-line User Library and either check the output directly, or send the output
to me. It is important, though, that you take the current version of
sysprofiler rather than the one included with your VnmrJ software / User
Library. I suspect that something in your networking setup is incorrect,
causing your system to run into a kind of "identity crisis", hence causing
X.11 to fail.

==
>From the information you provided, I can only suspect that the problem is in the X server. I have never seen anything like this happening before. I don't understand how vnmrj could mess up your X configuration but that is my guess. I don't think, from what you tell me below, that the problem is network-related or IP-related. If you can log in remotely, you can take a look at the X server configuration in /etc/X11/xorg.conf or examine the bootup messages (dmesg | less) for clues. The xorg.conf file can be re-creted with "Xorg -configure": see for example http://www.freebsd.org/doc/handbook/x-config.html.

You can also try to log in remotely from another linux machine and run the graphics utilities on your remote computer. You can run system-config-display to reconfigure the X server to something usable. Use "ssh -X remotesystem" to log in with X forwarding. You could even try to run vnmrj remotely.

== I did try to reinstall nvidia driver as suggested here, but it has no effect
The VJ installer probably assumes you have an Nvidia graphics card, like
all of the Dell computers sold by Varian.

Does your computer have an Nvidia card? If not, is it trying to use an
Nvidia driver? If it does, is the Nvidia driver being used, or a generic
Xorg configuration?

I run the software on both Varian-supplied and not-Varian-supplied
workstations, and on the not-Varian-supplied one, which does have an
Nvidia card, I found I had to download and install the driver from the
Nvidia website to have working graphics after installing the VJ.

== I did not try this yet since it is a little involved with the firewall arrangement
I don't have VnmrJ 3.1 but have 2.3A. Did you try using Redhat Linux
which seems to be the default OS for VnmrJ ?

Could you setup a temporary user account for me to remotely log in and
take a look? Please let me know the IP address also. I can't guarantee
to locate the problem, but would like to give it a try.

==
Any chance you have a flaky video card/cable/monitor?

It sounds like a heck of a coincidence, but maybe something is crashing the video card or causing your monitor to temporarily die about the same time you finish the VJ installation. The <CTRL><ALT><F2> is pretty low level, so it seems unlikely to me to be a software issue, especially as you can log in remotely.

Maybe try changing the video card, cable and monitor. I think you have a hardware issue.

==
It seems likely that VJ3.1 is resetting the display configuration files in such a way that X cannot start AND doesn't realize it is dead. Basically, when you log out, the X server is stopped and then restarted and it is then that the confused configuration file is being read. Thus, dead in the water. The issue seems to be that the VJ configuration files are not appropriate for your hardware and software level. You are correct that VJ should not do this, but they do.

Another option is to backup the display configuration file manually, install VJ, then copy your backup over the file that VJ puts in.

I have repaired these things manually in the past on my own systems from an emergency command line (Red Hat) by booting up into the single user, emergency mode but don't remember the details and so probably would not be efficient.

Hopefully, another person who is a "guru" (I am not) will point you in the right direction. My observation above may help you and them get there.

==
We have several NMR instruments and workstations using Centos... upgraded
to 5.6+ and with VnmrJ 2.2D. We've never seen that kind of problem.

>From what you say, I would recommend using a static IP address if you can.
VJ does have some weird issues with host names.

All that being said, I have not yet messed with 3.1 which arrived a few
weeks ago.

There is a recent libX11 update that addresses some other stability
issues. You might try that specific update.
Received on Tue Nov 15 2011 - 12:49:53 MST

This archive was generated by hypermail 2.4.0 : Sat Jun 17 2023 - 15:11:49 MST