Hi everyone,

A few days ago I posted a question about the GDM not working properly on
SL7.1.  Our machines at the institute are provisioned using Spacewalk
services and we have created our own repositories.  On one of our
repositories there was the kmod-nvidia and xorg-x11-drv-340xx package
included which was installed automatically during the installation.  The
machines which had Intel graphics were affected by these packages,
preventing GDM from starting. 

Once these packages were removed and the machine was restarted, 
everything seemed to work fine.  My apologies for all the noise.

Thank you everyone, especially Patrick who was involved in solving this
problem. It was a great experience to see different approaches to the
problem.

Valentin    

On 09/23/2015 08:24 PM, Thompson, Herb wrote:
> By any chance are you trying to install SL7 on an HP laptop?  Some HP laptops have both an Intel graphics controller and an NVIDIA controller enabled simultaneously. This confuses the NVIDA Linux drivers.  The solution for me was to use the BIOS settings to disable the Intel graphics controller.  The NVIDA driver worked after that.
>
> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Valentin B
> Sent: September-18-15 11:45 AM
> To: Pat Riehecky; [log in to unmask]
> Subject: Re: [SCIENTIFIC-LINUX-DEVEL] Scientific Linux support
>
> 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
>
> ________________________________
> This e-mail communication (including any or all attachments) is intended only for the use of the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient of this e-mail, any use, review, retransmission, distribution, dissemination, copying, printing, or other use of, or taking of any action in reliance upon this e-mail, is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the original and any copy of this e-mail and any printout thereof, immediately. Your co-operation is appreciated.
> Le présent courriel (y compris toute pièce jointe) s'adresse uniquement à son destinataire, qu'il soit une personne ou un organisme, et pourrait comporter des renseignements privilégiés ou confidentiels. Si vous n'êtes pas le destinataire du courriel, il est interdit d'utiliser, de revoir, de retransmettre, de distribuer, de disséminer, de copier ou d'imprimer ce courriel, d'agir en vous y fiant ou de vous en servir de toute autre façon. Si vous avez reçu le présent courriel par erreur, prière de communiquer avec l'expéditeur et d'éliminer l'original du courriel, ainsi que toute copie électronique ou imprimée de celui-ci, immédiatement. Nous sommes reconnaissants de votre collaboration.