Unable to login under Fedora 28 after update

[xcommy]

Hi!

I am using NoMachine for a very long time now and use it on a Fedora 28 machine using a virtual display (that means, the window manager on the local console is off, as I had problems with a black screen)

After one of the last packet updates the virtual session fails to start and I am unable to login. I have switched on debugging and think, that this might be the problem. I do not know, where to look further or how to solve this:


2018-08-28 08:59:31 845.419  4377 NXNODE   Process '/bin/bash -c exec -a - /bin/bash -c '/etc/gdm/Xsession '\''gnome-session --session=gnome'\'' with pid '4427/4427' finished with signal 15 after 1,304 seconds.
2018-08-28 08:59:31 845.511  4377 NXNODE   session monitor: application finished.
2018-08-28 08:59:31 845.623  4377 NXNODE   session monitor: is not agent closing '1'.
2018-08-28 08:59:31 845.707  4377 NXNODE   session monitor: is disabled terminate on sigchild ''.
2018-08-28 08:59:31 845.798  4377 NXNODE   This session is terminate on SIGCHLD, dont need receive status from Agent.
2018-08-28 08:59:31 845.876  4377 NXNODE   session monitor: no others applications to wait going to shutting down session
2018-08-28 08:59:31 846.127  4377 NXNODE   ERROR! Application terminated too early.


Regards,

Matthias

[kroy]

We haven’t problems with sessions on upgraded Fedora 28. Is there any core dump, produced by any program (even by a NX program, although this would be rather bad 😉 ) in Fedora’s home directory, when session fails? That would be useful.

Please enable debug on server side, restart nxserver (sudo /usr/NX/bin/nxserver --restart) and reproduce problem. Compressed nxserver logs (/usr/NX/var/log/ directory) and .xsession-errors file from home directory send to forum[at]nomachine[dot]com.

Instructions about debug and collecting logs you can find there: https://www.nomachine.com/DT10O00163

[xcommy]

Hi!

Thanks for the answer. I have sent the logs. A core dump was not to be found.

Matthias

[graywolf]

Matthias,

Didn’t you find any file named .xsession-errors in the user’s home directory?

Could you dump the journal (sudo journalctl -b > journal.txt) and send it to us, too?

[xcommy]

Hi!

I have sent the journal.txt. The .xsession-errors exist, but is empty.

Matthias

[graywolf]

Please try this:

Install xterm: sudo dnf install xterm
Edit node.cfg to change DefaultDesktopCommand: DefaultDesktopCommand "xterm"
Run the session, you’ll get a virtual screen with only a terminal window
Run the command /usr/libexec/gnome-session-check-accelerated in the terminal window and let me know the result.

[xcommy]

Actually I have researched a bit further and there may be a problem with modern sessions.

I managed to get a working desktop with a MATE desktop environment. Should the command above work also in this session? I don’t get any output from that command.

Matthias

[graywolf]

You should get something like this: llvmpipe (LLVM 6.0, 256 bits)

Would you tell me the results of command glxinfo | grep render and ldconfig -p | grep libGL?

[xcommy]

Hi!

There seems to be something has deactivated/was deactivated after upgrade:

[matthias@localhost ~]$ /usr/libexec/gnome-session-check-accelerated
[matthias@localhost ~]$ glxinfo | grep render
Error: couldn't find RGB GLX visual or fbconfig
[matthias@localhost ~]$ ldconfig -p | grep libGL
libGLdispatch.so.0 (libc6,x86-64) => /lib64/libGLdispatch.so.0
libGLX_mesa.so.0 (libc6,x86-64) => /lib64/libGLX_mesa.so.0
libGLX.so.0 (libc6,x86-64) => /lib64/libGLX.so.0
libGLU.so.1 (libc6,x86-64) => /lib64/libGLU.so.1
libGLEW.so.2.0 (libc6,x86-64) => /lib64/libGLEW.so.2.0
libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2
libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1
libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1


[graywolf]

Matthias, please

1. Check if both packages “mesa-libGL” and “libglvnd-glx” are installed:

sudo rpm -qa mesa-libGL libglvnd-glx

2. If mesa-libGL is not installed, please install it:

sudo dnf install mesa-libGL

3. Check if files or symlinks “libGLX_indirect.so.0” and “libGLX_mesa.so.0” exist:

ls -l /usr/lib64/libGLX_indirect.so.0 /usr/lib64/libGLX_mesa.so.0

4. If libGLX_indirect.so.0 doesn’t exist, create the symlink to libGLX_mesa.so.0:

ln -s /usr/lib64/libGLX_mesa.so.0 /usr/lib64/libGLX_indirect.so.0

5. Check if problem is solved.

[xcommy]

Hi!

The link to libGLX_indirect.so.0 was not there so that does the trick and the session works again.

Matthias

[Author]

Posts