Bug 862798 - ttys are not started except for tty1
Summary: ttys are not started except for tty1
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F18Blocker, F18FinalBlocker
TreeView+ depends on / blocked
Reported: 2012-10-03 14:58 UTC by Kamil Páral
Modified: 2012-10-04 10:20 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-10-04 10:20:42 UTC

Attachments (Terms of Use)
messages (375.59 KB, text/plain)
2012-10-03 14:59 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2012-10-03 14:58:14 UTC
Description of problem:
I installed F18 Beta TC1 (any architecture) from PXE. The installed system boots and works, but only tty1 (with gdm) is functional. If I switch to any other tty, only blinking underscore is there. No login prompt, hitting keys does nothing. I tried to reboot several times, no help. I have seen this on two different machines.

When I install from Live, other ttys work.

I have some weird feeling that systemd is now in charge of spawning ttys, so reporting against it.

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

How reproducible:

Steps to Reproduce:
1. install F18 Beta TC1 over PXE
2. ctrl+alt+f2

Comment 1 Kamil Páral 2012-10-03 14:59:42 UTC
Created attachment 620971 [details]

Comment 2 Kamil Páral 2012-10-03 15:00:35 UTC
This could potentially be a blocker, or NTH.

Comment 3 Jóhann B. Guðmundsson 2012-10-03 15:16:11 UTC
Do you have an login prompt if you boot into the multiuser-target?

Under what blocker criteria do you think this falls under?

Comment 4 Kamil Páral 2012-10-03 15:44:06 UTC
enforcing=0 on the boot line fixes this. Reassigning.

Comment 5 Kamil Páral 2012-10-03 15:46:09 UTC
Btw, it can be also reproduced with netinst installations.

Booting into runlevel 3 produces working tty1, but no other tty again.

Comment 6 Kamil Páral 2012-10-03 15:52:37 UTC

Comment 7 Bill Nottingham 2012-10-03 15:55:54 UTC
From what I understand, this is due more to internal selinux code inside systemd than due to the policy itself. Dan?

Comment 8 Kamil Páral 2012-10-04 10:20:42 UTC
The problem happens with systemd-193-13fc18. The problem is solved with systemd-194-1.fc18. (no selinux-policy change needed).

Because systemd-194-1.fc18 is now in stable updates, closing.

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