search

clearlinux / distribution

Placeholder repository to allow filing of general bugs/issues/etc against the Clear Linux OS for Intel Architecture linux distribution
521 stars 29 forks source link

nvidia 2060 rtx: Black screen after login live usb #791

Open Enumeration opened 5 years ago

Enumeration commented 5 years ago

Hi,

I've tried CL last week, before my new graphics card arrived and it worked fine (Intel integrated). Now I've got issues opening the desktop environment using a nvidia 2060 rtx card.

The usb boots and presents a login screen. I am presented with a black screen (and unmovable mouse), after pressing the login button. The login screen pops back up after a few seconds. Rinse and repeat.

Last used CL version: 29590 live-desktop x64

I've attached dmesg and journalctl logs. I'm fairly new to linux, you'll have to do a bit of hand holding if you need more information.

E.

dmesg_.txt journalctl_.txt

ahkok commented 5 years ago

The support for this card may not yet be enabled in the driver chain. Since we follow upstream releases, we may just need to wait.

znmeb commented 5 years ago

Try adding modprobe.blacklist=nouveau to the kernel command line before booting. nouveau can't handle recent NVidia GPUs.

lebensterben commented 5 years ago

There's a tutorial on documentation page of Clear Linux, on how to install the NVIDIA proprietary driver.

If you have a integrated GPU on your motherboard, maybe you can try to connect to that GPU during installation of Clear Linux, and then install the NVIDIA driver.

Enumeration commented 5 years ago

The support for this card may not yet be enabled in the driver chain. Since we follow upstream releases, we may just need to wait.

Strange. Ubuntu 19.04 based operating systems don't have these issues on a live usb, while Ubuntu 18.04 based operating systems do (like CL). What's the difference between CL and Ubuntu 19.04 (when comparing upstream drivers)?

Try adding modprobe.blacklist=nouveau to the kernel command line before booting. nouveau can't handle recent NVidia GPUs.

Thank you, but it gives me access to the console, not to the desktop environment as I'd like.

There's a tutorial on documentation page of Clear Linux, on how to install the NVIDIA proprietary driver.

I've tried installing that monstrosity on Mint and gave up at some point. Or maybe I was just following a bad tutorial. I'll try the tutorial after installing CL tonight and see where it gets me.

lebensterben commented 5 years ago

@Enumeration Let me know if you need help on installing the drivers.

P.S. Clear Linux is not Ubuntu-based.

Sent with GitHawk

miguelinux commented 5 years ago

I know CL isn't Ubuntu based but they both use a Nouveau driver, right?

Right, but they have different kernel versions.

Have you tried with the LTS2018 kernel?

Enumeration commented 5 years ago

@Enumeration Let me know if you need help on installing the drivers.

I managed to install the proprietary drivers, I'm having issues though with the settings application. gnome-control-center -v yields:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
(gnome-control-center:7477): GLib-CRITICAL **: 23:31:02.075: g_strsplit: assertion 'string != NULL' failed
Segmentation fault (core dumped)

Have you tried with the LTS2018 kernel?

I haven't yet. I'll try tomorrow.

lebensterben commented 5 years ago

@miguelinux @Enumeration I've seen the same error after installing NVIDIA driver. And gnome-control-center is the only application that's not working.

puneetse commented 5 years ago

I've seen the same error after installing NVIDIA driver. And gnome-control-center is the only application that's not working.

I'm not sure why this is either. If you do export LD_LIBRARY_PATH=/opt/nvidia/lib:$LD_LIBRARY_PATH it'll at least let you launch it for the session. The ld.so.conf.d file should be taking care of that though.

miguelinux commented 5 years ago

Also,

Looks like it is an Gnome Shell issue: https://github.com/clearlinux/distribution/issues/749

lebensterben commented 5 years ago

@miguelinux @puneetse Another approach proved to work is to delete libGL.so under /use/lib64/ directory.

Sent with GitHawk

sunnyflunk commented 5 years ago

So looks like at some point it is loading the incorrect libGL. I have fixed pretty much the same issue previously with the NVIDIA drivers.

libcairo-gobject.so.2 seems like a possible culprit as it's used by gnome-control-center, has RUNPATH /usr/lib64 set and links to libGL.

libtool is meant to set RPATH only when the directory isn't in the dynamic linker search path. Unfortunately it's detection system is not good and breaks with the stateless approach (no /etc). This means that /usr/lib64 is set as an RPATH as only /usr/lib is used as a fallback. CLR uses --enable-new-dtags so this is usually linked as RUNPATH, but this still causes issues as it's loading the RUNPATH before the standard inbuilt paths. A quick example:

$ gcc minigzip.c -o minigzip -lz -Wl,-rpath,/tmp/rpath -Wl,--enable-new-dtags
$ readelf -d minigzip | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [/tmp/rpath]
$ ldd minigzip | grep libz
        libz.so.1 => /tmp/rpath/libz.so.1 (0x00007f6b69e17000)
$ LD_LIBRARY_PATH=/usr/lib64 ldd minigzip | grep libz
        libz.so.1 => /usr/lib64/haswell/libz.so.1 (0x00007f2ca30cf000)

I ended up adding export LT_SYS_LIBRARY_PATH=/usr/lib64 to builds to adjust the dynamic linker detected paths, there is likely a better approach.

There were also some pkgconfig files which would set RPATH to be inherited by other builds (SDL for example).