Bug 623430 - getty on tty1 is not visible at first
getty on tty1 is not visible at first
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
14
All Linux
low Severity high
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-08-11 15:02 EDT by Michal Schmidt
Modified: 2010-08-18 21:09 EDT (History)
6 users (show)

See Also:
Fixed In Version: systemd-7-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-18 21:09:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2010-08-11 15:02:25 EDT
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@tty1.service and plymouth-quit.service.

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

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 15:57:06 EDT
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-11 21:26:54 EDT
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-11 21:42:32 EDT
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-11 22:25:51 EDT
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-11 22:31:05 EDT
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-11 22:52:09 EDT
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-11 22:52:43 EDT
commited, built and bodhi ticket filed.
Comment 8 Adam Williamson 2010-08-12 10:33:48 EDT
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 15:48:14 EDT
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-18 21:09:13 EDT
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.

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