I'd defiantly start with a clean xorg.conf... mv /etc/X11/xorg.conf /etc/X11/xorg.conf.$$ mv /etc/X11/xorg.conf.d /etc/X11/xorg.conf.d.$$ mkdir -m 755 /etc/X11/xorg.conf.d/ and see what you get from egrep 'EE|WW' /var/log/Xorg.0.log after a reboot. Pat On 09/18/2015 10:09 AM, Valentin B wrote: > Pat, > > The problem seems to occur only on Intel graphics. The nvidia cards > seem not to be affected. > > [root@fischer ~]# lsmod |grep i915 > i915 929459 4 > i2c_algo_bit 13413 1 i915 > drm_kms_helper 98226 1 i915 > drm 311588 3 i915,drm_kms_helper > i2c_core 40325 5 > drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit > video 19263 2 i915,asus_wmi > > I've also tried to put nomodeset as kernel parameter but the results > remain the same. > > Any clue? > > On 09/18/2015 04:46 PM, Pat Riehecky wrote: >> In that case you may want to move the config file out of the way, >> autodetect works pretty well in 7. >> >> Pat >> >> On 09/18/2015 09:44 AM, Valentin B wrote: >>> I've messed up earlier with the xorg.conf file which I per accident >>> did put nvidia as a drivier. The machine in question does not have >>> an nvidia. At least according to lspci: >>> >>> 00:02.0 VGA compatible controller: Intel Corporation 4th Generation >>> Core Processor Family Integrated Graphics Controller (rev 06) >>> >>> >>> >>> On 09/18/2015 04:41 PM, Pat Riehecky wrote: >>>> Odds are: >>>> >>>> /var/log/Xorg.0.log:[ 11.590] (EE) Failed to initialize GLX >>>> extension (Compatible NVIDIA X driver not found) >>>> >>>> is the cause of your error. >>>> >>>> I'd suggest the ELrepo Nvidia modules: >>>> >>>> yum -y install yum-conf-elrepo >>>> yum -y install nvidia-detect >>>> yum install $(nvidia-detect) >>>> >>>> May fix your issue, or it may not...... >>>> >>>> Pat >>>> >>>> On 09/18/2015 09:39 AM, Valentin B wrote: >>>>> This is what I'm getting: >>>>> >>>>> http://sprunge.us/ceeI >>>>> >>>>> On 09/18/2015 04:36 PM, Pat Riehecky wrote: >>>>>> Anything interesting from: >>>>>> >>>>>> egrep 'EE|WW' /var/log/Xorg.* >>>>>> >>>>>> >>>>>> Pat >>>>>> >>>>>> On 09/18/2015 09:33 AM, Valentin B wrote: >>>>>>> Hello Pat and Armando, >>>>>>> >>>>>>> Thank you very much for your great explanation. Based on your >>>>>>> writing, it seems there is no reason to switch. I therefore >>>>>>> would like to take the opportunity to explain the following. >>>>>>> >>>>>>> Since SL7 has implemented systemd init system, we are having a >>>>>>> few issues with the migration process. The problems arose with >>>>>>> the migration to SL7.1 which won't boot to GDM. These issues >>>>>>> were not present on SL7.0. >>>>>>> >>>>>>> Looking at the logs e.g journalctl -b | grep gdm results into >>>>>>> the following: >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: Child >>>>>>> process 2117 was already dead. >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: >>>>>>> GdmDisplay: display lasted 0.057283 seconds >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl dbus-daemon[723]: >>>>>>> dbus[723]: [system] Rejected send message, 1 matched rules; >>>>>>> type="method_call", sender=":1.17" (uid=0 pid=1023 >>>>>>> comm="/usr/sbin/gdm ") >>>>>>> interface="org.freedesktop.DBus.Properties" member="GetAll" >>>>>>> error name="(unset)" requested_reply="0" destination=":1.23" >>>>>>> (uid=0 pid=2118 comm="/usr/libexec/gdm-simple-slave --display-id >>>>>>> /org/gn") >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl dbus[723]: [system] >>>>>>> Rejected send message, 1 matched rules; type="method_call", >>>>>>> sender=":1.17" (uid=0 pid=1023 comm="/usr/sbin/gdm ") >>>>>>> interface="org.freedesktop.DBus.Properties" member="GetAll" >>>>>>> error name="(unset)" requested_reply="0" destination=":1.23" >>>>>>> (uid=0 pid=2118 comm="/usr/libexec/gdm-simple-slave --display-id >>>>>>> /org/gn") >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: Child >>>>>>> process 2123 was already dead. >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: >>>>>>> GdmDisplay: display lasted 0.056510 seconds >>>>>>> >>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: >>>>>>> GdmLocalDisplayFactory: maximum number of X display failures >>>>>>> reached: check X server log for errors >>>>>>> >>>>>>> >>>>>>> I've done a lot of googling and stumbled upon a few bug reports >>>>>>> regarding this issue. Is this a known problem? Is there a fix? >>>>>>> >>>>>>> Thanks again for your time! >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> Valentin >>>>>>> >>>>>>> On 09/18/2015 04:19 PM, Pat Riehecky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Thanks for your interest in Scientific Linux. Fermilab >>>>>>>> continues to be the primary sponsor of Scientific Linux, with >>>>>>>> some assistance from DESY and ETHZ (OpenAFS and Live Media). >>>>>>>> >>>>>>>> We plan to continue development of SL. While the future is >>>>>>>> hard to predict, there are currently no indications that will >>>>>>>> change. The Fermilab computing infrastructure relies on SL. >>>>>>>> >>>>>>>> In terms of moving from 6 to 7, we recommend a complete >>>>>>>> re-install[1]. As a whole the OS feels very different. There is >>>>>>>> a lot to like about this new release, and a lot that is very >>>>>>>> very different. Whatever your plans, I strongly recommend >>>>>>>> reading the Upstream Release Notes (a link is present within >>>>>>>> the SL notes)[2]. I would encourage a review of the SL release >>>>>>>> notes >>>>>>>> >>>>>>>> We are still planning a customization framework for local >>>>>>>> contexts - like Sites and Spins from SL5 and SL6 with less >>>>>>>> overhead, but that work is still pending. An easy customization >>>>>>>> framework may be useful for Kapteyn. >>>>>>>> >>>>>>>> I hope this information is helpful, >>>>>>>> >>>>>>>> Pat >>>>>>>> >>>>>>>> [1] >>>>>>>> http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_upgrading_from_sl_6 >>>>>>>> [2] >>>>>>>> http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_the_upstream_vendor_8217_s_release_notes >>>>>>>> >>>>>>>> On 09/18/2015 07:00 AM, Valentin B wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> In our faculty (Kapteyn astronomical institute) we are using >>>>>>>>> Scientific Linux 6 on our servers and client machines. >>>>>>>>> Recently, we've >>>>>>>>> considered to migrate to Scientific Linux 7 but are not sure >>>>>>>>> if this >>>>>>>>> is the right move to make. CentOS7 is also a potential >>>>>>>>> consideration >>>>>>>>> but we cannot confirm if this is the right way either. >>>>>>>>> >>>>>>>>> Is Fermilab and CERN still involved in the development and >>>>>>>>> maintenance >>>>>>>>> of Scientific Linux and for how long? Should we still choose >>>>>>>>> to use >>>>>>>>> SL6 and migrate to SL7 or would we better be off using CentOS? >>>>>>>>> What >>>>>>>>> potential problems could we be facing migrating to SL7? Can >>>>>>>>> one of >>>>>>>>> you shed some light on this? >>>>>>>>> >>>>>>>>> Thanks in advance! >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org