What do you get from:
systemctl status gdm.service
Pat
On 09/18/2015 10:23 AM, Valentin B wrote:
> This is what I'm getting:
>
> [root@fallows ~]# egrep 'EE|WW' /var/log/Xorg.0.log
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [ 12.963] Initializing built-in extension MIT-SCREEN-SAVER
> [ 13.023] (WW) Falling back to old probe method for modesetting
> [ 13.023] (WW) Falling back to old probe method for fbdev
> [ 13.024] (WW) Falling back to old probe method for vesa
> [ 13.122] (WW) evdev: Chicony HP Elite USB Keyboard: ignoring
> absolute axes.
>
>
> Screen remains just blank and does not present a login screen
>
> On 09/18/2015 05:18 PM, Pat Riehecky wrote:
>> 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
|
