[root@fallows ~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
Active: active (running) since Fri 2015-09-18 17:29:58 CEST; 15s ago
Process: 1039 ExecStartPost=/bin/bash -c TERM=linux /usr/bin/clear >
/dev/tty1 (code=exited, status=0/SUCCESS)
Main PID: 1025 (gdm)
CGroup: /system.slice/gdm.service
├─1025 /usr/sbin/gdm
├─1043 /usr/libexec/gdm-simple-slave --display-id
/org/gnome/DisplayManager/Displays/_0
└─2091 /usr/bin/Xorg :0 -background none -verbose -auth
/run/gdm/auth-for-gdm-PC5wRz/database -seat seat0 -nolisten tcp vt1
Sep 18 17:29:58 fallows.intra.astro.rug.nl systemd[1]: Started GNOME
Display Manager.
This is all.
On 09/18/2015 05:28 PM, Pat Riehecky wrote:
> 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!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
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
|
