Bug 3819 - From the latest systemd update (208-26) no login prompt on tty1
: From the latest systemd update (208-26) no login prompt on tty1
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: x86_64 Linux
: High critical
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
Depends on:
  Show dependency treegraph
Reported: 2014-02-26 17:32 MSK by Giovanni Mariani
Modified: 2015-05-15 20:27 MSD (History)
3 users (show)

See Also:
RPM Package: systemd-208-30.src.rpm
Bad POT generating:

System log from a successful boot (136.57 KB, text/plain)
2014-02-26 17:32 MSK, Giovanni Mariani

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Mariani 2014-02-26 17:32:29 MSK
Created attachment 2678 [details]
System log from a successful boot

Description of problem:
I had configured the PC to boot always in text mode.

After updating the systemd packages to the 208-26 release a couple of days ago, at every boot the process halts before showing the login prompt, the last message on the screen being "Starting Wait for Plymouth Boot Screen to Quit...".

By switching to another VT (ie ctrl+alt+Fn, with n not equal to "1") I can actually log-in and do some useful work; tty1 however stays hung.
Also, while the single mode boot is working, doing a "systemctl default" from the single mode tty1 results in a similar hang.

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

How reproducible:

Steps to Reproduce:
1. Install the latest systemd packages
2. Reboot in text mode
3. Wait a while with the screen message "Starting Wait for Plymouth Boot Screen to Quit..."
4. Switch console (eg ctrl+alt+F2)
5. Watch the login prompt appear
6. Log successfully
Comment 1 Eugene Shatokhin 2014-02-27 12:22:49 MSK
Yes, it is a known problem. The work on a fix is in progress.
Comment 2 Aleksandr Kazantcev 2014-02-27 12:23:52 MSK
This is error in KDM and plymouth - you may try remove splash=silent from grub.cfg
Comment 3 Giovanni Mariani 2014-06-24 19:16:58 MSD
(In reply to comment #2)
> This is error in KDM and plymouth - you may try remove splash=silent from
> grub.cfg

The real thing is that we miss a stupid symlink...

Despite its name, Logind from newer systemd has nothing to do with user login and accepting user input: both things are a getty task.

There is a getty@.service in /lib/systemd/system, to be launched after a service suspiciously named "plymouth-quit-wait.service", but it does nothing per se: it needs someone telling to it on what tty it has to be spanned...

Short story: when booting in text mode, to restore the showing of the prompt on tty1 we only need a symlink named "getty@tty1.service", pointing to /lib/systemd/system/getty@.service, in /etc/systemd/system/multi-user.target.wants.

Simply adding it fixes the reported problem.
Comment 4 Giovanni Mariani 2014-06-24 19:41:57 MSD
By looking at the spec file for systemd I noticed the snippet below in the %post section for the latest systemd-units package (208-34):
if [ $1 -eq 1 ] ; then
# Try to read default runlevel from the old inittab if it exists
runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null)
if [ -z "$runlevel" ] ; then

# And symlink what we found to the new-style default.target
/bin/ln -sf "$target" %{_sysconfdir}/systemd/system/default.target 2>&1 || :

# Enable the services we install by default.
/bin/systemctl --quiet enable \
                getty@tty1.service \
                remote-fs.target \
                systemd-readahead-replay.service \
                systemd-readahead-collect.service \
                2>&1 || :
The last item indeed should produce the desired symlink (in getty.target.wants rather than in multi-user.target.wants, as I stated previously), but - at least in my system - it did not.

I guess the reason is in the initial test: "if [ $1 -eq 1 ]" only test for installation, not for upgrade, so when updating from an older systemd release we could end up without the needed symlinks for the above services...

And you guess... also systemd-readahead-replay.service and systemd-readahead-collect.service were disabled on my system.
Comment 5 Denis Silakov 2015-05-15 17:09:17 MSD
Is this issue still valid with modern systemd?
Comment 6 Giovanni Mariani 2015-05-15 20:27:58 MSD
(In reply to comment #5)
> Is this issue still valid with modern systemd?
No. The latest package (208-53) works.
It it impossible to launch the default DE with "startx", but this deserves another bug report...