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