This is my first post, so apologies if I not followed the forum’s etiquette.
I am trying to switch to Rocky 9.4 from CentOS 7 on my ten-year-old server
with its twin identical monitors and a GeForce 750 graphics card, but have
failed.
Under CentOS, the monitors are connected via the server’s two HDMI ports to
each monitor’s DVI socket, and the dual display works fine. However, if I
boot with Rocky 9.4 from an external SSD, nothing appears on the monitors
after the boot has completed. I can only see a display and login if I
connect the server’s sole VGA port to one of the terminals, and nothing is
seen on the second monitor. Indeed xrandr --listactivemonitors only
regards that one VGA monitor is active, whereas under CentOS two HDMI
monitors are active.
First I tried installing the latest version of the Nvidia drivers, both
from Nvidia and from RPM Fusion, and the 470 version from RPM Fusion,
all without success in enabling both monitors. I wanted to try 390, as this
seems to be the version recommended for GTX 750 by Nvidia (although nvidia-detect responds kmod-nvidia), but the install finds no match for
xorg-x11-drv-nvidia-390xx. This was after updating my system to
5.14.0-503.23.2.el9.x86_64. The window manager is MATE. There is no
secure boot.
Is there some configuration file that needs editing, or some command that
enables Rocky to recognise the HDMI-connected monitors? Is the HDMI->DVI
not supported by the newer Nvidia drivers or Rocky, and hence should I buy
a VGA splitter?
I fear that after lots of attempts I may have some hybrid set of nvidia
packages installed. What’s the recommended way to clear out the nvidia
packages, to start afresh?
Many thanks for any answers to my questions, or suggestions on how proceed.
I don’t think anybody provides this anymore, if you didn’t find it in rpmfusion, another place to search would be elrepo, but I’ve checked that as well, and they no longer have the nvidia driver for 390. It is recommended for that card now to just use the nouveau driver that comes with Linux. If that doesn’t work, you would have to try and use the rpm packages directly from NVidia for the 390 - assuming you can find them. I have a laptop which requires NVidia 470xx drivers, and newer drivers do not work for it. I also know that these will disappear at somepoint in the future, and will then also have to just use nouveau if I cannot find the 470xx ones when they are deprecated.
It should work with HDMI. I would be tempted though to remove the NVidia drivers you’ve installed so far, and just try the default nouveau driver and see what happens? If it works and performs enough for your needs with just the nouveau driver, maybe that would be enough? Sure, it may not have the full 3D performance like the Nvidia ones, but if it’s just normal PC usage it may be enough?
The proprietary NVidia drivers should include documentation, both as README.txt and html pages. This is definitely true for RPM’s from NVidia’s CUDA repo and ELRepo.
(I did rpm -qda \*nvidia\* to seek such files.)
Docs in driver version 570.86.15 have:
Current NVIDIA GPUs
NVIDIA GPU product
Device PCI ID
VDPAU features
NVIDIA GeForce GTX 750 Ti
1380
E
NVIDIA GeForce GTX 750
1381
E
NVIDIA GeForce GTX 860M
1392
E
NVIDIA GeForce GPU
1392 1028 066A
E
NVIDIA GeForce GTX 750 Ti
1392 1043 861E
E
NVIDIA GeForce GTX 750 Ti
1392 1043 86D9
E
NVIDIA GeForce GTX 750 Ti
139B 1025 107A
E
NVIDIA GeForce GTX 860M
139B 1028 06A3
E
NVIDIA GeForce GTX 960A
139B 103C 2B4C
E
NVIDIA GeForce GTX 750Ti
139B 17AA 3649
E
NVIDIA GeForce GTX 960A
139B 17AA 36BF
E
NVIDIA GeForce GTX 750 Ti
139B 19DA C248
E
NVIDIA GeForce GTX 750Ti
139B 1AFA 8A75
E
NVIDIA GeForce GTX 750 Ti
139D
E
In other words, even the very latest NVidia drivers should support some “GeForce 750” chips.
Note though that NVidia’s CUDA repo has two driver 570 versions: open and dkms. The open does not support pre-Turing chips; only the “closed” dkms version does.
As a new/recent thing, the 570-dkms allows Wayland, which still has issues on NVidia. One might have to explicitly disable Wayland, unless MATE does that. (This might affect Nouveau behaviour too.)
I have had machines (HP/Dell?) with both older and recent NVidia (latest was Ada Lovelace), where Nouveau of the installer fails to use the discrete card, so the install had to use IGP (or VNC, etc). I’ve also had machines, where (either Nouveau or proprietary) cannot show any virtual consoles – even though the (X11) GUI is ok.
I usually dnf rm \*nvidia\*, and possibly dnf module reset nvidia-driver (if CUDA repo was used), and check:
A belated thank you for your detailed reply. I needed my machine back for a while, and
I have only been able to continue the investigation in the last couple of days,
I believe that I installed the driver with the dkms version.
I too had found that the 570 driver should be fine with the GeForce GTX 750, hence
I wondered if it was the /etc/X11/xorg.conf that was preventing the HDMI access, as
it only had one each of Monitor, Device, and Screen sections. I substituted a slightly
modified CentOS 7 version and that seemed to pass muster (checked /var/log/Xorg.0.log), but Lightdm failed and thus no graphical login appeared. The log
reports “(EE) No devices detected…(EE) no screens found,” immediately after stating
that it was using the NVIDIA 570.124.06 driver. The Device entries in xorg,conf have
the driver set to “nvidia”. The nouveau option is disabled in the grub,
I’d like to post the configuration file and log, in case somebody can a spot a flaw or
suggest why no devices are detected, but I’ve yet to find the compose control to
permit that or verbatim pasting.
I can certainly try the Nouveau, although its far from ideal.
Given that the NVidia driver that the CentOS 7 system has installed does the job,
perhaps I should see if that driver version is available to install instead of 570. Are there
likely to be conflicts with later kernels/libraries?
You can post the config by copying/pasting into the reply box here, using the formatting tools, eg:
my nvidia config here
that will show it correctly formatted and make it easier for people to read. The tools above the reply box shows an icon </> which is the code formatting tool (which I’ve used in my example above).
Can you also try by renaming xorg.conf to xorg.conf.backup - nowadays an xorg.conf shouldn’t be needed. After renaming it, restart the computer and check the Xorg.0.log after this.
Thank you for the suggestion. I tried this awhile back and again today, but the
result is the same—only one screen is active. On my CentOS system once
the ghostly 7 logo appears on the right screen, which is connected via DVI, the
login graphic appears on the left screen, and the right screen goes blank until I
disconnect its DVI cable. A simple reboot without connecting the DVI cable works,
but nothing appears on either display until the login prompt. I only connect the
DVI cable when I need to interact with the boot process.
The system administrator, now retired, who helped set this up ca. 2017 was puzzled
too by this quirky behaviour. My feeling, if not a strong recollection, is that he made
some configuration change to permit display to both screens once the reboot
completes, which is missing from my Rocky 9 installation. IIRC this unusual screen
behaviour started after some nightly upgrade, that probably included a kernel
change.
Perhaps this machine needs to be cleanly installed, rather than upgraded from CentOS 7 which is unsupported anyway? Also, we don’t even know if the problem is introduced due to strange config files from CentOS 7. Even more so since the machine will have gone from Rocky 8 to Rocky 9 during the upgrade process. Or do I misunderstand you, in that you dualboot between CentOS 7 and Rocky 9?
Can you try different monitors? Perhaps ones that have HDMI ports instead of DVI ones, instead of converting/switching between HDMI/DVI connections?
Furthermore, the NVidia driver does write to /var/log/Xorg.0.log its enumeration of ports on the card and what monitors it saw on them. If it sees displays, then why it does not draw / draws funky?
If you can still run the CentOS 7, then how its Xorg.0.log differs?
An another thing is that there are GDM, Gnome, and X11/Wayland.
One definitely can give X11 instructions about displays, but one can also override setup in Gnome – per user – and even copy that to GDM (for all users). That is two systems for some operations – Xorg and GDM/Gnome – and I had hard time to find whom to blame. In other words, that “clean slate” could really help.
The 570 series driver packages from NVidia’s repo allow Wayland. Previously, GDM did disable Wayland with NVidia drivers. One can still do that by uncommenting line
#WaylandEnable=false
from /etc/gdm/custom.conf
That could make a difference on what the GDM does/tries to show before anyone logs in.
Did you do already the elementary “boot with only first monitor connected, boot with only test monitor connected” to show that each monitor&cable is fine alone?
How about a switch to virtual console (i.e. Ctrl-Alt-F2, Ctrl-Alt-F3, …)?
With GDM the login dialog is probably on the “primary” display.
(With LightDM the login dialog seems to show on the display that does have the mouse – i.e. follows the mouse, but that is an another story.)
There was no upgrade. That was my original attempt, and none of the upgrade tools
completed successfully. So I setup a new SSD with a boot partition, swap space and
an LVM with three logical volumes, the first of which is where I installed Rocky 9.
There’s no dual booting. It boots Rocky 9 from the external SSD if that’s powered,
otherwise it boots CentOS 7 from the internal SSD.
I’ll check to see if I copied any other files besides xorg.conf from CentOS 7 /etc to the
Rocky 9 equivalent. The problem with the displays was present before I did that. The
copy was an attempt to overcome the matter.
