Bug 682285 - No getty on tty3+
Summary: No getty on tty3+
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-04 18:11 UTC by Mads Kiilerich
Modified: 2011-07-05 12:02 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-03-07 12:44:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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?


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