Re: [elrepo] Dual boot rhel 7.5 - gui not starting
So I scrutinized my Xorg.log file as suggested and found some lines showing failures: *[28.568] (EE) Failed to load /usr/lib64/xorg/modules/extensions/nvidia/libglx.so: libnvidia-tls.so.390.59: cannot open shared object file: No such file or directory* *[28.568] (II) UnloadModule: "glx"* *[28.568] (II) Unloading glx* *[28.568] (EE) Failed to load module "glx" (loader failed, 7)* *...* *...* *[28.700] (EE) [drm] Failed to open DRM device for (null): -2* *[28.710] (II) modeset(0): using drv /dev/dri/card1* *[28.710] (WW) Falling back to old probe method for fbdev* I checked the directories and the missing shared object is actually in /usr/lib64/nvidia. However, I have configured my bumblebee.conf file exactly as specified in the bumblebee wiki which has the XorgModulePath specifying the directory path which fails above. I don't think I should be attempting to change the directory path for XorgModulePath to point to /usr/lib64/nvidia since the bumblebee wiki does not say to do that. On Tue, 29 May 2018 at 09:58, Akemi Yagi wrote: > On Sat, May 26, 2018 at 4:40 PM, Akemi Yagi wrote: > > On Sat, May 26, 2018 at 2:45 PM, John Adegbile > wrote: > >> > >> On Sat, 26 May 2018 at 01:13, Akemi Yagi wrote: > >>> > >>> On Fri, May 25, 2018 at 7:20 PM, John Adegbile > > >>> wrote: > >>> > Hello, > >>> > > >>> > I am struggling a bit to get a GUI installation completed on my MSI > >>> > GS63VR > >>> > laptop. It comes with windows 10 and I have dual booted with RHEL > 7.5 . > >>> > I > >>> > have completed the rhel installation and have installed the nvidia > >>> > drivers > >>> > from elrepo. > >>> > > >>> > I can't get the GUI to work though. Would someone kindly be able to > give > >>> > me > >>> > some pointers as to where I'm going wrong? I have enabled default > >>> > graphical.target via systemctl but the GUI does not launch. The > error I > >>> > get > >>> > when I attempt to run startx manually is: > >>> > > >>> > [ 1740.462] (EE) Screen(s) found, but none have a usable > configuration. > >>> > Fatal server error: > >>> > [ 1740.462] (EE) no screens found(EE) > >>> > [ 1740.463] (EE) > >>> > > >>> > Output of lspci is: > >>> > 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev > >>> > 04) > >>> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP106M [GeForce > >>> > GTX > >>> > 1060 Mobile] (rev a1) > >>> > > >>> > Output of nvidia-detect is: > >>> > Probing for supported NVIDIA devices... > >>> > [10de:1c20] NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile] > >>> > This device requires the current 390.59 NVIDIA driver kmod-nvidia > >>> > [8086:591b] Intel Corporation Device 591b > >>> > > >>> > RPMs installed: > >>> > nvidia-x11-drv-390.59-1.el7_5.elrepo.x86_64 > >>> > yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch > >>> > kmod-nvidia-390.59-1.el7_5.elrepo.x86_64 > >>> > nvidia-detect-390.59-1.el7.elrepo.x86_64 > >>> > > >>> > uname -a: > >>> > 3.10.0-862.3.2.el7.x86_64 > >>> > > >>> > Thanks in advance > >>> > > >>> > J > >>> > >>> You seem to have two graphics devices, an integrated graphics (Intel) > >>> and an Nvidia card. Can you disable the former in the BIOS? If this is > >>> not possible, you need to make use of the Nvidia Optimus technology. > >>> For detailed instructions, please see the bumblebee wiki page at: > >>> > >>> http://elrepo.org/tiki/bumblebee > >>> > >>> Akemi > > > >> Thanks for the tip. > >> > >> I installed and configured bumblebee (using primus as an alternative to > >> optirun). I followed the instructions and machine now hangs when I get > to: > >> [OK] Started GNOME display Manager. > >> [OK] Started Virtualization daemon. > > > > Did you see any error message while installing the required packages? > > No steps missed when configuring it? > > > > Not using it myself, I cannot provide better support than referring > > you to what has already been written. There is an instruction note > > given by a CentOS user: > > > > > https://www.centos.org/forums/viewtopic.php?f=49=61162=10#p266381 > > > > It's basically the same except the addition of the last step (10). > > > > Akemi > > I'm copying a message from Nicolas Thierry-Mieg below. Hope this helps > you figure out why things are not working. > > Akemi > > "you might have some useful info in /var/log/Xorg.* > > I had set up bumblebee on my son's laptop in the past and had to move > some things around, because [some reason, can't remember the details > but it was something like X not looking in the correct folders for the > 2 cards]. Carefully reading through the Xorg.* logfiles had allowed me > to find the source problem. I can look it up one of these evenings if > needed." > ___ > elrepo mailing list > elrepo@lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo > ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] Announcement: EL7 Updated kernel-lt Package Set [4.4.135-1]
Announcing the release of the kernel-lt-4.4.135-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.135 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-4.4.135-1.el7.elrepo.x86_64.rpm kernel-lt-devel-4.4.135-1.el7.elrepo.x86_64.rpm kernel-lt-doc-4.4.135-1.el7.elrepo.noarch.rpm kernel-lt-headers-4.4.135-1.el7.elrepo.x86_64.rpm kernel-lt-tools-4.4.135-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-4.4.135-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-4.4.135-1.el7.elrepo.x86_64.rpm perf-4.4.135-1.el7.elrepo.x86_64.rpm python-perf-4.4.135-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-4.4.135-1.el7.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-7 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-lt may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-lt packages in regular service. The packages are intentionally named kernel-lt so as not to conflict with the RHEL-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] Announcement: EL6 Updated kernel-lt Package Set [4.4.135-1]
Announcing the release of the kernel-lt-4.4.135-1.el6.elrepo package set into the EL6 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.135 The following files are currently synchronising to our mirror sites: x86_32 kernel-lt-4.4.135-1.el6.elrepo.i686.rpm kernel-lt-devel-4.4.135-1.el6.elrepo.i686.rpm kernel-lt-doc-4.4.135-1.el6.elrepo.noarch.rpm kernel-lt-headers-4.4.135-1.el6.elrepo.i386.rpm kernel-lt-NONPAE-4.4.135-1.el6.elrepo.i686.rpm kernel-lt-NONPAE-devel-4.4.135-1.el6.elrepo.i686.rpm perf-4.4.135-1.el6.elrepo.i686.rpm python-perf-4.4.135-1.el6.elrepo.i686.rpm x86_64 kernel-lt-4.4.135-1.el6.elrepo.x86_64.rpm kernel-lt-devel-4.4.135-1.el6.elrepo.x86_64.rpm kernel-lt-doc-4.4.135-1.el6.elrepo.noarch.rpm kernel-lt-headers-4.4.135-1.el6.elrepo.x86_64.rpm perf-4.4.135-1.el6.elrepo.x86_64.rpm python-perf-4.4.135-1.el6.elrepo.x86_64.rpm nosrc kernel-lt-4.4.135-1.el6.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-6 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-lt may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-lt packages in regular service. The packages are intentionally named kernel-lt so as not to conflict with the RHEL-6 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-6 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
