Bug 623430

Summary:	getty on tty1 is not visible at first
Product:	[Fedora] Fedora	Reporter:	Michal Schmidt <mschmidt>
Component:	systemd	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	14	CC:	awilliam, lpoetter, metherid, mschmidt, notting, rstrode
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	systemd-7-3.fc14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-19 01:09:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	538278

Description Michal Schmidt 2010-08-11 19:02:25 UTC

Description of problem:
As noted by Adam Williamson in
https://bugzilla.redhat.com/show_bug.cgi?id=623102#c12:
  after booting live, installing, and booting with parameter '3',
  which causes systemd to go down its multi-user.target path.
  After firstboot runs, you wind up at a black screen; you can either
  hit ctrl-alt-f2 to get to tty2, or ctrl-c and then tty1 pops up.

It's caused by wrong ordering of getty and plymouth-quit.service.

plymouth-quit.service has:
After=getty
but it should be:
Before=getty

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

How reproducible:
always

Steps to Reproduce:
1. boot with the parameter '3'
  
Actual results:
After booting finishes, the login prompt is not seen.

Expected results:
The login prompt should be visible.

Comment 1 Adam Williamson 2010-08-11 19:57:06 UTC

Thanks, Michal. Adding this to F14Alpha blocker list for consideration at the go/no-go meeting. It's a borderline judgement call: we don't actually have criteria to cover text mode boot, but this is probably an oversight that should be rectified - we should have something to complement the graphical criterion, "In most cases, the installed system must boot to a functional graphical environment without user intervention (see Blocker_Bug_FAQ)". The question is just how broken can it be before we consider it too bad to ship; can we assume people booting to a console should know to try ctrl-alt-f2 or ctrl-c to get to a boot prompt, or is it unacceptable if they don't see one right on startup?

Note this bug is similar to https://bugzilla.redhat.com/show_bug.cgi?id=623102 in impact, but not the same bug. That one manifests when you do a traditional install without X included, which would usually happen by doing a minimal install.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Adam Williamson 2010-08-12 01:26:54 UTC

Discussed at today's go/no-go meeting. We decided this doesn't constitute an Alpha blocker. We plan to take the fix for rc4 if available by tomorrow afternoon, however, as it's a simple and clearly correct change and gives a substantial benefit.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Adam Williamson 2010-08-12 01:42:32 UTC

Just to be clear: Lennart, Michal, Bill, Rahul - if one of you could please prepare a new f14 build of systemd with the above change included, and submit it as an update via Bodhi, ASAP - ideally by tomorrow morning US time - then we can get it fixed in Alpha. If not, we probably can't. Thanks a lot!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Lennart Poettering 2010-08-12 02:25:51 UTC

Hmm, I will make this fix, though I am a bit puzzled about this. In particular, I would have expected that "plymouth quit" does not clear the screen but restores what has been printed on it in the bg. Ray, can you comment on that?

Comment 5 Adam Williamson 2010-08-12 02:31:05 UTC

Release criterion proposal is http://lists.fedoraproject.org/pipermail/test/2010-August/092615.html .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Fedora Update System 2010-08-12 02:52:09 UTC

systemd-7-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/systemd-7-2.fc14

Comment 7 Lennart Poettering 2010-08-12 02:52:43 UTC

commited, built and bodhi ticket filed.

Comment 8 Adam Williamson 2010-08-12 14:33:48 UTC

Just tested this fix, it works fine. Tested booting the live image to runlevel 3, installing from live and booting runlevel 3 with firstboot active, and installing from live and booting runlevel 3 without firstboot active: I get a working tty1 each time.

But can you do a systemd 7-3 with the fix from https://bugzilla.redhat.com/show_bug.cgi?id=623561 ? Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Fedora Update System 2010-08-12 19:48:14 UTC

systemd-7-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update systemd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/systemd-7-3.fc14

Comment 10 Fedora Update System 2010-08-19 01:09:13 UTC

systemd-7-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.