Bug 735703 - VT now working properly with the nouveau driver
Summary: VT now working properly with the nouveau driver
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-05 04:31 UTC by bodhi.zazen
Modified: 2018-04-11 15:12 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-07 15:00:49 UTC

Attachments (Terms of Use)

Description bodhi.zazen 2011-09-05 04:31:08 UTC
Description of problem: Virtual terminals now working properly

Version-Release number of selected component (if applicable):

How reproducible: Fire up live CD, liveuser logs in automatically

Try to change between terminals (consoles) with ctrl-alt-F1

Steps to Reproduce:
1. Switch between consoles F1-F7
Actual results:

Neither VT 1 and 2 worked 
VT1 has boot messages, no login prompt
VT2 is blank , no login prompt

X was on VT 3

VT4,5,and 6 were all working (could log in)

Expected results:

X on VT 1
VT 2,3,4,5, and 6 otherwise work

Additional info: Nouveau test day , live CD, daily build 9-05-2011

Comment 1 Matěj Cepl 2011-09-05 14:07:49 UTC
This is done by other parts of Fedora. Reassigning to gdm, but please push this into right direction as necessary.

Comment 2 Lennart Poettering 2011-09-19 23:07:43 UTC
This can happen if some application blocks the tty. In that case logind won't spawn a getty on it.

"fuser -v /dev/tty2" is a way to figure out which process has it open.

Comment 3 bodhi.zazen 2011-09-22 03:53:37 UTC
fuser -v /dev/tty2

/dev/tty2  root   Xorg

fuser -v tty1 returns nothing 

My understanding is Xorg is supposed to be on tty1 , but the fuser command returns nothing and tty1 is not working.

Comment 4 Fedora Admin XMLRPC Client 2011-10-20 16:30:42 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Ian Dall 2011-11-30 11:11:05 UTC
Maybe this is nothing to do with nouveau. I have a laptop with i915 integrated graphics. If I boot to multi-user.target and remotely log in with ssh, I see a getty on tty1 only. As I understand it this is as expected. Now "systemctl isolate graphical.target" and the getty on tty1 is stopped (again as expected), but Xorg is running on tty2.

There are *two* log files /var/log/Xorg.0.log and /var/log/Xorg.1.log with the same modified time.

There is one Xorg process running: /usr/bin/Xorg :1 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-7mmnoS/database -nolisten tcp.

According to /var/log/Xorg.0.log, the server on display 0 exited cleanly.

It might seem that what is happening is that gdm is starting *two* xservers, probably on tty1 and tty2 but the first server is for some reason ephemeral, however this can't be the whole story as explained below.

Now go back to multi-user.target, and manually stop the getty on tty1 "systemctl stop getty@tty1.service". Check with fuser that nothing has any of the /dev/tty? open.

Now start and X server by hand with "Xorg&" and still there is nothing running on any of /dev/tty? except for

 # fuser /dev/tty2
/dev/tty2:           18085
 # ps -fp 18085
root     18085  2050  0 21:26 tty2     00:00:00 Xorg

Of course, gdm never even ran, so I suspect an Xorg server problem. Now only one log file (Xorg.0.log) is created, but for some reason the "use first free virtual terminal" algorithm isn't working.

Lastly, kill the previously started Xorg and start a new one with "Xorg vt1&" and there is an X server running as expected on /dev/tty1.

Comment 6 Jóhann B. Guðmundsson 2012-01-29 15:15:42 UTC
Looks like X is at fault here but first and foremost is this still an issue with all the latest updates?

Comment 7 Michal Schmidt 2012-06-07 15:00:49 UTC
In needinfo? for several months. Closing.

Note You need to log in before you can comment on or make changes to this bug.