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