Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ttys are not started except for tty1|
|Product:||[Fedora] Fedora||Reporter:||Kamil Páral <kparal>|
|Component:||selinux-policy||Assignee:||Miroslav Grepl <mgrepl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||dominick.grift, dwalsh, johannbg, lnykryn, metherid, mgrepl, msekleta, notting, plautrba, systemd-maint, vpavlin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-10-04 06:20:42 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Kamil Páral 2012-10-03 10:58:14 EDT
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): systemd-193-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. install F18 Beta TC1 over PXE 2. ctrl+alt+f2
Comment 2 Kamil Páral 2012-10-03 11:00:35 EDT
This could potentially be a blocker, or NTH.
Comment 3 Jóhann B. Guðmundsson 2012-10-03 11:16:11 EDT
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 11:44:06 EDT
enforcing=0 on the boot line fixes this. Reassigning.
Comment 5 Kamil Páral 2012-10-03 11:46:09 EDT
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 11:52:37 EDT
Comment 7 Bill Nottingham 2012-10-03 11:55:54 EDT
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 06:20:42 EDT
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.