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.
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
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
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
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?
Release criterion proposal is http://lists.fedoraproject.org/pipermail/test/2010-August/092615.html . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
systemd-7-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/systemd-7-2.fc14
commited, built and bodhi ticket filed.
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
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
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.