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