All of that looks like it should be working.....
Pat
On 09/18/2015 10:33 AM, Valentin B wrote:
> [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!
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Pat Riehecky
Scientific Linux developer
Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
|
