View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003459Kali LinuxGeneral Bugpublic2016-07-31 02:472025-07-14 09:38
Reportermcdee Assigned Torhertzog  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionunable to reproduce 
Product Version2016.1 
Summary0003459: Using Startx from TTY session crashes on Screen Lock
Description

After updating to kernel 4.6.0 via apt-get dist-upgrade and restarting the computer I noticed my tty session was still active. Running startx took me to the desktop where all went well. After a short period of inactivity (approx 5mins) the screen-locks as expected. However, attempting to gain access to the GUI again proved unsuccessful.

Attempting to log into a different tty with same username as previous session is rejected. However, any other user account on the system is allowed access to the GUI again via startx or using desktop manager.

Signing in using only the Desktop Manager does not appear to have this effect.

Steps To Reproduce

1: Start a TTY session using ctrl+alt+fn (other than 7)
2: Enter user name and password as normal
3: Run startx from terminal session to gain GUI access
4: Allow the screen to sleep or lock
5: Attempt to restore the session: Notice the screen is all black and will not respond to any keypresses

Additional Information

I've reproduced this crash several times. It only occurred after upgrade to Kernel 4.6.0. Upgrade was performed using apt-get dist-upgrade.

Note: It also affects previous Kernel 4.5 as a by-product of Kernel 4.6 being installed.

Solution: A way to get back into GUI from TTY session requires new login using different username.

Additionally, users logging into GUI via DM are not affected by this crash.
Even intiial log in then joining a tty session and allowing screen to sleep does not reproduce this crash.

Activities

rhertzog

rhertzog

2016-09-15 13:22

administrator   ~0005870

What desktop are you using?

If it's XFCE, then 0003527 might be a duplicate of this bug.

Do you still have the problem with a fully up-to-date kali-rolling system?
ccmcdee

ccmcdee

2016-09-15 19:54

reporter   ~0005894

Last edited: 2016-09-15 19:57

This was on XFCE4. the system is up-to-date. Since recently, I've switched to gnome and replicated the steps but with different results. The issue does not seem to arise in gnome3. And yes, I believe it was an xserver issue. Same as with in gnome where: xserver-xorg-input-synaptics disrupts/disables the tap-to-click options under Settings >> Hardware: Mousepad.

Issue History

Date Modified Username Field Change
2016-07-31 02:47 mcdee New Issue
2016-09-15 13:22 rhertzog Note Added: 0005870
2016-09-15 13:22 rhertzog Assigned To => rhertzog
2016-09-15 13:22 rhertzog Status new => feedback
2016-09-15 19:54 ccmcdee Note Added: 0005894
2016-09-15 19:57 ccmcdee Note Edited: 0005894
2017-02-04 15:40 rhertzog Status feedback => closed
2017-02-04 15:40 rhertzog Resolution open => unable to reproduce
2025-07-14 09:38 g0tmi1k Severity crash => minor