After installing xrdp and tigervnc-server, no output on the primary monitor

Latest response

After installing xrdp and tigervnc-server on RHEL 7.5 I do not get video on my primary monitor. I am able to RDP to the box and login successfully to a remote GNOME session. While booting up, as soon as the process completes and when I am supposed to be presented with GDM login screen, the display goes blank. None of the Ctrl-Alt combo works either.

Responses

Hello Lungten,

When you say, "After installing xrdp and tigervnc-server on RHEL 7.5 I do not get video on my primary monitor." Do you mean the primary monitor of the machine you are physically sitting at when remoting? Or the target?

Thanks, Joe

Hello Lungsten,

Did you set up your .vnc/xstartup file on the machine you are using to connect to the target? Also there are some resize options in the tabs of the Tiger vnc view you may want to check out.

Thanks, Joe

Hello Lungsten,

I got to looking at a server I configure for vnc use awhile back and remember you have to set up the desktop settings on both ends before it will work.

Thanks, Joe

Basically I am not getting video on the monitor which is connected to the onboard video port. I am able to login to the desktop session remotely over RDP. I can see the normal boot process but the video goes blank as soon as the graphical session starts.

I am not sure what additional configurations are required but this problem seems to occur only on the physical server. I tried to reproduce this inside a VirtualBox installation but no problem there.

Had the video worked before on this physical server? IF/When it worked before was the server running RedHat?

The video you get via RDP is not the same as the X driver, kernel, module, etc that drives the physical onboard video.

In regards to a display on the physical monitor, is it in good working order? Have you hooked it up to another machine to verify?

The video port is the only one available on the machine? There isn't a second port provided by PCI card? This is the onboard video?

If the physical hardware has been verified are you able to get to a cmdline? Some things to check would be. I also included the output from my own machine to show you what it might look like.

  1. lspci

lspci | grep -i vga

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)

  1. lsmod

lsmod | grep -i intel

video 15582 2 i915

Then modinfo. modinfo i915

filename: /lib/modules/3.10.0-957.1.3.el7.x86_64/kernel/drivers/gpu/drm/i915/i915.ko.xz license: GPL and additional rights description: Intel Graphics author: Intel Corporation author: Tungsten Graphics, Inc.

  1. journalctl | grep -i intel

I look to see if there are any device messages for my HW, Drivers, etc.

I guess I am curious were you able to look for any of this? I usually follow steps like this when troubleshooting devices where something might have gone wrong.

@Joe, thanks for the tips. I didn't try all this because I am confident that my video card or the monitor does not have problem. I have a couple of Supermicro servers running RHEL 7.5 which are all setup the same way and the problem occurs across all of them.

If i change the default-target to multi-user instead of the graphical I am able to login to the tty/console. The problem is when the default-target is graphical, I momentarily see a RHEL7 splash screen when GDM is about to launch. That is when the monitor goes blank as if there's a second monitor on which the GDM is displayed. After this, the server is non-responsive to any mouse or keyboard event. I am able to perform remote logins - SSH/RDP.

Ha, well I can honestly this is new one on me. :) That said I got to googling some of the keywords you gave me.

Would you mind looking over:

https://bugzilla.redhat.com/show_bug.cgi?id=828197

It is a bit dated, but it wouldn't hurt to run through some of the things they spoke of in the article. I googled using the search words, "bugzilla redhat systemctl default targert no desktop".

Also for the sake of comparisons. I looked at my laptop default. It is indeed graphical, but I would suspect that is the norm for all desktops and servers unless you are purposely building a headless machine.

So thinking about a headless server and a graphically desktop or server. These are options at install time. I did a quick compare of my desktop and a headless machine I purposely built as a file server and as expected the default on the laptop is graphical.target and the default on the file server is multi-user.target.

Though you are seeing graphical as your default off the bat and not changing it blindly. It is definitely interesting. When you flip it from graphical, to multi-user, back to graphical, does the problem clear? Can you see GDM?

Your thoughts?

When you flip it from graphical, to multi-user, back to graphical, does the problem clear? Can you see GDM?

Yes, I've tried this and once the boot process completes I get that blank screen instead of GDM.

I was digging through the logs and this is what I found:

gdm: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors

It appears GDM fails to display on the monitor. Now I am doubting that XRDP might have messed up my Xorg configuration but it is not so straight-forward to figure out the culprit. Still working on it.

With regard to https://bugzilla.redhat.com/show_bug.cgi?id=828197, I started with graphical installation so, my graphical.target was enabled by default. I tried switching between the two targets to confirm that it was the graphical mode causing the problem.

Finally got the solution - it was a matter of adding nomodeset to the GRUB command line.

Under /etc/default/grub:

GRUB_CMDLINE_LINUX="crashkernel=auto ... rhgb quiet nomodeset"

Then, of course:

grub2-mkconfig -o /boot/grub2/grub.cfg
shutdown -r now

Thank you, Joe Saunders, for trying to help. Much appreciated.

Hello Lungten,

Well thanks for letting hang out and learn something. Like I said, this was a new one on me. I feel like I ought to save this conversation in case it comes up on my end some day.

Would you mind letting me know how you found that? Once you said nomodeset. I got to searching and there are others who experienced this, but no one is really saying why it is happening or how they found out.

Like this one....

https://www.dell.com/support/article/us/en/04/sln306327/manual-nomodeset-kernel-boot-line-option-for-linux-booting?lang=en

Joe, My colleague raised a ticket with the RH technical support is nomodeset is one of the options provided to try.

It is really weird how none of the error messages I saw hinted at the kernel parameter. No Linux forums have these info either. I have been tinkering with Xorg and GDM config to no avail. Moreover the GDM/GNOME was running fine until we installed XRDP. I am thinking that some Xorg driver packages that got installed with XRDP could have messed up the kernel modesetting.

Thanks for letting me know.

Thinking about what you said in regards to Xorg getting pulled in with the Xrdp install. I ran yum deplist xrdp from my CentOS workstation just to see what would come back.

My workstation is CentOS Linux release 7.6.1810 (Core).

Lo and behold, I see xorg-x11-xinit and xorgxrdp in the response. I'll have to hunt around for RHEL 7 server with xrdp to compare, but would expect to see the same.

When you run the same command, do you see the same?

Yes, the dependency list has xorg-x11-xinit and xorgxrdp. Just wondering if there is a way to get around this issue without nomodeset.

Here is another one with the same fix. The funny thing is he refers to nomodeset as, "anyone runs into this problem what is needed is the famous (for ATI/AMD hardware on linux) nomodeset boot option to the kernel."

That one left me scratching my head. Since he said, "Famous"!

I have used ATI/AMD for years and can't remember ever having to use that setting to get any distribution of Linux to run GDM, KDE, whatever.

https://forum.rockstor.com/t/blank-console-ati-hardware-fix-supplied/702

Ok, this guy is better at describing why you'd need it. Its all good in the end. I got to learns something new! Thanks.

https://ubuntuforums.org/showthread.php?t=1613132

What are these options?

nomodeset The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesnt work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded.

Note that this option is sometimes needed for nVidia cards when using the default "nouveau" drivers. Installing proprietary nvidia drivers usually makes this option no longer necessary, so it may not be needed to make this option permanent, just for one boot until you installed the nvidia drivers.

This was an interesting explanation too from the Fedora forum.

https://ask.fedoraproject.org/en/question/46846/what-does-nomodeset-do/