Questions[display](server)

Posting here instead of unix exchange because although unix is the suject, this should apply to other non-nix OSs.

Our development team has been asked to automate some tasks that happen to interact with an industrial equipment running, get this, Solaris 2.5.1, which as far as i can tell is equivalent to SunOS 5.5.1. considering none of them are experienced with this version of solaris, which came out in 1995, I am now tasked to provide a development environment, including a VM or otherwise a machine running that version of Solaris.

I have acquired an iso for the install CD, along with images of the 3 boot floppies that came with the CD. I managed to boot by following the official doc for installing that version (put floppy 1, then 2, then 3 + CD and boot into the CD from floppy 3). i originally experienced a problem when first booting into the CD, where the hyper-V VM would crash when launching the installer. I have fixed that by reducing the max amount of memory allowed in NUMA settings from all 256GB to only 512MB.

Now the installer (sometimes) boots correctly, but the display is all wrong. I can just about make out the "F2 continue" prompt, so i can technically go through the installer, but selection any option is hell and i'm not even sure that the options are displayed next to their appropriate checkboxes. I'm pretty sure at some point i'm being asked to select graphical options but there are upwards of 50 of them and I can't read half of them.

The screenshot shown is the interactive installer. the installer can also use a jumpstart script, which I don't have nor know how to acquire. I suspect there might be a resolution for my problem here, but it's ever so slightly out of my reach.

My question is: Is there any way for me to somehow load or otherwise enforce drivers in order for hyper-V to correctly interpret the display information being sent out by Solaris? Am i just better off finding an early 2000s machine and trying to install it on there? I expect this problem is not exclusive to Solaris but is just an artifact of old OSs not quite being compatible with modern hosts.

Some extra info:

• host is Win server 2012 R2, Hyper-V. The VM is running in a cluster, if that matters.
• the VM is Gen 1 and has 1 core and 512 MB of ram assigned, dynamic allocation off, Hyper-v compatibility mode on, NUMA settings are 1 core, 512 MB RAM.

The setup is the following: VMWare ESXi5.0 Virtualisation server running a virtual machine Win7. This virtual machine is configured to have 2x Generic Non-PNP displays both at 1920x1200 resolution. The virtual machine runs fine, has RealVNC server 5.3.1 and I can get a VNC connection and remote desktop no problem.

The client machine is a Linux Mint desktop with 3x real displays, two of which are 1920x1200 resolution. This runs RealVNC Client 5.3. I can get a VNC window on the Win7 machine, but it is one big display 3840x1200 which can only be displayed fully when scaled and dragged across 2x client screens. This is messy and awkward and the scaling destroys the text.

Can anyone tell me how to configure the RealVNC server and client so the 2x displays of the Win7 machine display full-screen on the 2x displays on the client in full screen. I've spent ages reading the RealVNC docs, they're not good but do indicate this should be possible. The server does export both displays; but how to get the client to display them separately. I'm not sure if I need 2 server instances and/or two client instances for each display separately.

If required I'd consider using another VNC setup, but better the devil you know. Thanks in advance

I'm looking for a proper display setup for us sysadmins here and I'm going to be picking out a monitor for us to use.

What features should I look for in a display that are appropriate for sysadmins that spend a lot of time staring at text on a screen?

What qualities are important in such displays?

What qualities reduce eyestrain?

I'm looking at getting a two-monitor setup for us.

I have a new and vexing problem with ssh forwarding my X11 connection when logging in from a Mac (10.7.2) to Linux (Ubuntu 8.04). I have no trouble using ssh -X to log in to the remote machine and starting an X11-based application from that shell.

What has recently started happening is that additional invocations of X11 applications from that same shell, after a while (on the order of hours), are unable to start because the forwarded display is being blocked (I presume). When attempting to start xterm, for example, I get the usual message about a bad DISPLAY setting, such as:

xterm Xt error: Can't open display: localhost:10.0

But the X11 application I started right when I logged in is still running along just fine, using that exact same display (localhost:10.0), just that it was started earlier.

I turned on verbose logging in sshd_config and I see this in the /var/log/auth.log file in response to the failed xterm startup attempt:

sshd[22104]: channel 8: open failed: administratively prohibited: open failed

If I ssh -X to the server again, starting a new shell and getting assigned a new display (localhost:11.0), the same process repeats: the X11 applications started early on run just fine for as long as I keep them open (days), but after a few hours I cannot start any new ones from that shell.

Particulars: OpenSSH sshd server running on Ubuntu 8.04, display forwarded to a Mac running Lion (10.7.2) with the default Apple X server. The systems are connected on an Ethernet LAN with a single switch between them. Neither machine is running a firewall. Until recently (a few days ago) this setup worked perfectly so I am mystified as to where to look next. I am by no means an X11 or SSH expert but have good UNIX/Linux experience. Nothing obvious has changed in either client or server configuration although I have tried changing a few options to try to debug this, like setting sshd_config's TCPKeepAlive to no, and setting "host +localhost" (you can tell I've been Googling).

When logging in from a Linux 11.10 laptop to the same remote host over the same network and switch, this problem does not occur -- an xterm can be invoked successfully hours later from the same ssh login shell while the same experiment from the Mac fails (tested this morning to be sure), so it would appear to be a Mac-specific issue.

With "LogLevel DEBUG3" set on the remote machine (sshd server), and no change made in the client connections by me, /var/log/auth.log shows one slight change in connection status reports overnight, which is the port number used by the one successful ssh session from the Linux machine (I think), connection #7 below:

sshd[20173]: debug3: channel 7: status: The following connections are open:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 14/13 cfd -1)\r\n #3 X11 connection from 127.0.0.1 port 57564 (t4 r1 i0/0 o0/0 fd 16/16 cfd -1)\r\n #4 X11 connection from 127.0.0.1 port 57565 (t4 r2 i0/0 o0/0 fd 17/17 cfd -1)\r\n #5 X11 connection from 127.0.0.1 port 57566 (t4 r3 i0/0 o0/0 fd 18/18 cfd -1)\r\n #6 X11 connection from 127.0.0.1 port 57567 (t4 r4 i0/0 o0/0 fd 19/19 cfd -1)\r\n #7 X11 connection from 127.0.0.1 port 59007

In this report, everything is the same between status reports except the port number used by connection #7 which I believe is the Linux client -- the only one still maintaining a display connection. It continues to increment over time, judging by a sequence of these reports overnight.

Thanks for any help,

-Mike

I have a ubuntu linux machine that I have already logged into and X server is running (it is pass the login manager like gdm). I can access this machine through ssh. My goal is to start x11vnc on this machine and attach it to the X server that is already running.

When I ssh into the machine and start x11vnc, it says:

X11 was unable to open the X DISPLAY ":0", it cannot continue.

How can I start x11vnc on the remote machine if I don't have physical access to it and Xserver has already started. The reason I want to do this is because the remote machine has several windows open that I want to work on.

EDIT: I also tried x11vnc -find. This time it didn't give me that error message and was able to detect that the client was connected:

Got connection from client x.x.x.x
...
wait_for_client: find display cmd failed
wait_for_client: bad reply '
'

So it seems like -find command just delays the inevitable.

Thanks,