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!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
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
|
