Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.System no longer boots to a blank screen when Xinerama is enabled
When the Xinerama extension was enabled in `/etc/X11/xorg.conf` on a system using the nvidia or nouveau driver, the RANDR X extension got disabled. Consequently, login screen failed to start upon boot due to the RANDR X extension being disabled. This bug has been fixed and the login screen now starts properly even with Xinerama enabled.
Description of problem:
Version-Release number Description of problem:
System booted to runlevel 5, with Xinerama enabled in Xorg.conf with either nvidia or nouveau driver gets stuck with blank screen. Tests are done with below mentioned cards:
VGA compatible controller: NVIDIA Corporation GK107GL [Quadro K2000] (rev a1)
VGA compatible controller [0300]: NVIDIA Corporation GK107 [GeForce GT 640] [10de:0fc1] (rev a1) (prog-if 00 [VGA controller])
VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
Version-Release number of selected component (if applicable):
gdm-3.26.2.1-5.el7
How reproducible:
Always
Steps to Reproduce:
1. On a system with nvidida card, configure X to enable Xinerama with nvidia/nouveau driver
2. Boot the system to runlevel 5
Actual results:
It never presents a login screen, instead presents a blank screen.
Expected results:
Botted in runlevel 5, it should prompt login screen to allow user to initiate session.
Additional info:
We test this on both Fedora 27 and Fedodar 28 as well but no luck, still the same result. of selected component (if applicable):
could it be, that your monitors.xml file is not setup correctly to end up having your login screen on the wrong display ?
Once you logged into your gdm session, configure your monitor setup and
copy the monitors.xml file :
cp ~/.config/monitors.xml /var/lib/gdm/.config/
I had the same problem and this fixed it.
I have a scratch build for 7.5 that tries to somewhat handle the lack of RANDR support in the X server by assuming the whole screen is a single dummy monitor. I can start GNOME Shell with this on a dual monitor setup and it'll work as if all connected monitors were just a single one. Naturally monitor configuration does no longer work with this.
Is this something that would work for the customer?
The scratch build is available here:
http://brew-task-repos.usersys.redhat.com/repos/scratch/jadahl/mutter/3.26.2/18.el7_5/
Here is another scratch build for 7.5. I have tested this on a system with nvidia, with two (separate) monitors using a config similar to the ones in the sosreports. The previous version did indeed crash when using the nvidia driver, but not in the driver as reported reported above, so I cannot verify the same crash is fixed.
The new coredump tarball also seems to not have contained any mutter or gnome-shell backtraces, so if the new scratch build still causes a crash, it'd be very useful to have the whole backtrace leading up to the crash.
Here is the new scratch build:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=18723238
Feedback from the customer with latest scratch build
*******
THAT WORKED!!!!!! I did see some core dumps. I didn't always get them when I booted up but I did get a few. They are attached. I tested with Xinerama disabled and enabled, both with 1 screen attached and 2 screens attached. It worked as desired in all 4 cases, but most importantly it worked in the desired case of 2 screens attached with Xinerama enabled.
*******
In the attached coredumps, I see, two of them belongs to gnome-shell.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2019:2044