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
|
