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! >>>>>> >>>>> >>>> >>> >> > -- Valentin Bajrami Kapteyn Astronomical Institute University of Groningen Postbus 800 NL-9700 AV Groningen The Netherlands Phone: +31-(0)50-3634068 URL: http://www.astro.rug.nl/~valentin