[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