Bug 682285

Summary: No getty on tty3+
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: a, johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-07 12:44:34 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:

Description Mads Kiilerich 2011-03-04 18:11:05 UTC
On my system upgraded to F15 with current -testing and systemd-19-1.fc15.i686 I see the systemd log on ctrl-alt-f1, X on ctrl-alt-f2, but ctrl-alt-f3 and later are empty. 

/etc/systemd/system/getty.target.wants/getty and others are in place, so I would expect a login prompt there.

Downgrading to systemd-18 makes it work (but also moves X to f7).

Comment 1 Lennart Poettering 2011-03-05 14:27:23 UTC
My guess is that plymouth is frozen and the gettys wait for that.

Doe the gettys appear if you wait a couple of minutes?

Comment 2 Mads Kiilerich 2011-03-05 22:29:16 UTC
I will check on monday, but I don't think so.

How can I check if plymouth is frozen? Is that if plymouthd is running because gdm haven't told it to quit?

Comment 3 Lennart Poettering 2011-03-06 14:41:43 UTC
Login remotely via ssh when this happens and then check with "ps" if there are "plymouth --wait" or "plymouth quit" processes hanging around.

Comment 4 Michal Schmidt 2011-03-07 08:50:56 UTC
Isn't this the same issue as reported by Andrey Borzenkov?: http://lists.freedesktop.org/archives/systemd-devel/2011-March/001424.html
and the related plymouth client bug:
http://lists.freedesktop.org/archives/systemd-devel/2011-February/001401.html

Comment 5 Mads Kiilerich 2011-03-07 10:51:16 UTC
"/bin/plymouth --wait" was running/hanging after boot, and killing it made the tty login prompts appear.

It seems like it works with plymouth-0.8.4-0.20110304.1.fc15.i686 . Is that expected?

This issue might be related to Andreys report, but it also seems wrong that /etc/X11/prefdm still runs "plymouth quit --retain-splash" and thus prevents gdm from doing it.

/lib/systemd/system/multi-user.target.wants/plymouth-quit.service also seems suspicious to me, but I don't fully grok systemd yet.

Comment 6 Michal Schmidt 2011-03-07 12:44:34 UTC
(In reply to comment #5)
> "/bin/plymouth --wait" was running/hanging after boot, and killing it made the
> tty login prompts appear.
> 
> It seems like it works with plymouth-0.8.4-0.20110304.1.fc15.i686 . Is that
> expected?

Yes. Andrey's fix for the infinite wait in plymouth was included in the update:
http://cgit.freedesktop.org/plymouth/commit/?id=32a214337b20a4417f5c5c0a28c208568dec567a

Closing this bug. The plymouth update is already on the way to stable:
https://admin.fedoraproject.org/updates/plymouth-0.8.4-0.20110304.1.fc15

> This issue might be related to Andreys report, but it also seems wrong that
> /etc/X11/prefdm still runs "plymouth quit --retain-splash" and thus prevents
> gdm from doing it.

Prevents gdm from doing what exactly?
If you see a problem in /etc/X11/prefdm, report it as a bug in initscripts.

> /lib/systemd/system/multi-user.target.wants/plymouth-quit.service also seems
> suspicious to me, but I don't fully grok systemd yet.

This one is only used if we're booting to multi-user.target (runlevel 3). prefdm.service has an intentional conflict with this service. So it's not used when booting into graphical.target (runlevel 5).

Comment 7 Mads Kiilerich 2011-03-07 15:36:45 UTC
See also Bug 682785 - No login prompt in runlevel 1 and s

Comment 8 Alexey Bozrikov 2011-07-05 12:02:15 UTC
This issue goes away once you do 'ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target'

Apparently, it happens to upgrade installations (from Fedora14, for example), where user changed to text mode by modifying /etc/inittab default runlevel. Could be addressed in upgrade procedure, maybe?