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