Setting minimum-vt < 7 in lightdm.conf breaks VT switching.

Bug #1457049 reported by oberon2007
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Confirmed
Undecided
Unassigned
Arch Linux
Confirmed
Undecided
Unassigned

Bug Description

With lightdm-1.14.0+ when booting, shortly before the greeter I see a console login screen for about 1sec.
When the greeter starts I only have one tty available (attempts to switch VTs result in a brief flash to black and then back to the greeter in the same state as before attempting to switch VTs.
After logging in its the same: only one tty or anyway Ctrl+Alt+1, 2, 3..., always shows the graphical tty.
After downgrading to lightdm 1:1.14.0-2 no problem. Update again, problem is back. The issue affects gtk and webkit greeters (that I have confirmed), but its possible that all greeters are affected.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System: Kernel: 4.0.3-1-MANJARO x86_64 (64 bit gcc: 4.9.2)
           Desktop: i3 4.10.2 Distro: ManjaroLinux 0.8.13rc1 Ascella
Machine: System: Acer product: TravelMate B115-M v: V1.26
           Mobo: Acer model: Roxy v: Type2 - A01 Board Version
           Bios: Insyde v: V1.26 date: 09/12/2014
CPU: Quad core Intel Pentium N3540 (-MCP-) cache: 1024 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 17314
           clock speeds: max: 2665 MHz 1: 499 MHz 2: 499 MHz 3: 499 MHz
           4: 499 MHz
Graphics: Card: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display
           bus-ID: 00:02.0
           Display Server: X.Org 1.17.1 driver: intel
           Resolution: 1366x768@60.06hz
           GLX Renderer: Mesa DRI Intel Bay Trail
           GLX Version: 3.0 Mesa 10.5.5 Direct Rendering: Yes

Report in Arch Linux: https://bugs.archlinux.org/task/46799.

oberon2007 (bernhard-c)
description: updated
Revision history for this message
oberon2007 (bernhard-c) wrote :

Here's the output of x-0.log during the attempts to switch ttys[code]Failed to switch from vt01 to vt02: Input/output error
(II) AIGLX: Suspending AIGLX clients for VT switch
Failed to switch from vt01 to vt03: Input/output error
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch[/code]
and the end of lightdm.log:[code][+26.79s] DEBUG: Activating VT 1
[+26.79s] DEBUG: Activating login1 session c2
[+26.80s] DEBUG: Seat seat0 changes active session to c2
[+26.80s] DEBUG: Session c2 is already active[/code]

Revision history for this message
oberon2007 (bernhard-c) wrote :

The problem does not occur every single time, but most of the times and it looks like it is more likely to happen when I try to switch tty after boot and BEFORE logging in. (So while the greeter is running). But then it persists for the session. Logout and back in seems to solve the problem - not completely sure about that, yet.

Revision history for this message
oberon2007 (bernhard-c) wrote :

When the problem is present, dm-tool lock is not working, either
While the session flashes briefly without being locked, the output of lightdm.log reads:

[+1156.47s] DEBUG: Seat seat0: Locking
[+1156.47s] DEBUG: Seat seat0: Creating greeter session
[+1156.47s] DEBUG: Seat seat0: Creating display server of type x
[+1156.47s] DEBUG: Using VT 4
[+1156.47s] DEBUG: Seat seat0: Starting local X display on VT 4
[+1156.47s] DEBUG: DisplayServer x-3: Logging to /var/log/lightdm/x-3.log
[+1156.47s] DEBUG: DisplayServer x-3: Writing X server authority to /run/lightdm/root/:3
[+1156.47s] DEBUG: DisplayServer x-3: Launching X Server
[+1156.47s] DEBUG: Launching process 2527: /usr/sbin/X :3 -seat seat0 -auth /run/lightdm/root/:3 -nolisten tcp vt4 -novtswitch
[+1156.47s] DEBUG: DisplayServer x-3: Waiting for ready signal from X server :3

Revision history for this message
oberon2007 (bernhard-c) wrote :

Logging out after the above attempt to lock session, I find the graphical session to be on tty4!
After logging back in and out and in, I am back on tty1 ... ...

Revision history for this message
oberon2007 (bernhard-c) wrote :

Settings minimum-vt=7 or commenting minimum-vt out seems to solve the problem.
Setting minimum-vt=1 produces the above mentioned problem on my system.

Revision history for this message
oberon2007 (bernhard-c) wrote :

Now I have a different problem:
When I lock the session (on tty7) with #dm-tool lock# the greeter appears as expected.
BUT:
When I switch to another tty and then back to tty7 the session is unlocked!

Revision history for this message
André Miranda (andreldm) wrote :

I'm facing the same problem, but the keyboard leds(numlock, capslock...) go crazy and whenever I close a windows with alt+f4 the screen flickers. It seems to be a regression of version 1:1.14.0-3(up to 1:1.14.2-1, same problems), so I stick with version 1:1.14.0-2.
I'm using Arch Linux x64 fully updated, Xfce 4.12, on three different systems(2 desktops and 1 laptop), so this doesn't seems to be a hardware specific problem.

summary: - lightdm problem since version 1:1.14.0-3
+ Setting minimum-vt < 7 in lightdm.conf breaks VT switching.
description: updated
Revision history for this message
Dustin Falgout (lots0logs) wrote :

Also worth noting is that the logs get filled with login failure messages from pam-tally which seem to indicate that all keyboard input is being captured on a login tty that cannot be accessed by the user. The issue does not occur if you comment-out the minimum-vt setting or simply change the value to the default (7).

Changed in lightdm:
status: New → Confirmed
Revision history for this message
Dustin Falgout (lots0logs) wrote :

This bug has security implications because while VT switching is broken, all keyboard input is being captured on what appears to be an inaccessible login terminal. Each time you hit the enter key a log-in attempt is made and, of course, fails. The failure is logged in the systemd journal. The journal message can (and often does) contain passwords the user entered into other services during normal use of their desktop.

Daniel Hahler (blueyed)
description: updated
Changed in archlinux:
status: New → Confirmed
Revision history for this message
kevinf (kevinf) wrote :

Still an issue as of 1:1.16.6-2 on ArchLinux. I changed minimum-vt=7 and problem solved. Before then, my logs were spammed.

Feb 07 20:58:07 carputer login[1882]: pam_tally(login:auth): pam_get_uid; no such user
Feb 07 20:58:07 carputer login[1882]: pam_unix(login:auth): check pass; user unknown
Feb 07 20:58:07 carputer login[1882]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=
Feb 07 20:58:09 carputer login[1882]: FAILED LOGIN 1 FROM tty1 FOR [6~[6~[5~[6~, Authentication failure
Feb 07 20:58:10 carputer login[1882]: pam_tally(login:auth): pam_get_uid; user?
Feb 07 20:58:10 carputer login[1882]: pam_unix(login:auth): check pass; user unknown
Feb 07 20:58:10 carputer login[1882]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=
Feb 07 20:58:11 carputer polkitd[598]: Unregistered Authentication Agent for unix-process:1872:142313 (system bus name :1.39, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8
Feb 07 20:58:11 carputer login[1882]: FAILED LOGIN SESSION FROM tty1 FOR nobody, Error in service module
Feb 07 20:58:15 carputer systemd[1]: <email address hidden>: Service has no hold-off time, scheduling restart.
Feb 07 20:58:15 carputer systemd[1]: Stopped Getty on tty1.
Feb 07 20:58:15 carputer systemd[1]: Started Getty on tty1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.