Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a fresh installation of Arch Linux, and I've enabled dhcpcd on eth0. However, the message output for dhcpcd startup appears after the OS is booted up and is at the login screen, so I get this:

Arch Linux booted showing dhcpcd messages after the login screen

How can I fix this?

share|improve this question
It's been a bug I have seen for a while. I just hit enter, and then it allows you to login. My guess is you will be setting up a login manager along with X, so in the future after that you won't even see it. – nerdwaller Jan 26 '13 at 6:42
No, not really; I am intending to run this as a server of various sorts with minimal overhead. – George K. Jan 26 '13 at 18:40
@GeorgeK. Can you show us how long it takes for dhcpcd to start? the output from systemd-analyze blame ? On my computer it takes 7 seconds or so (really long time for my standards) yet I see no messages on top of the login prompt. Also as a remedial solution, you can add quiet to your kernel line on you bootloader. – Martín Canaval Jan 26 '13 at 18:51
Running systemd-analyze blame spits out the following: Traceback (most recent call last): File "/usr/bin/systemd-analyze", line 23, in <module> from gi.repository import Gio ImportError: No module named gi.repository. I'm assuming that I don't have the gi module installed?.. – George K. Jan 26 '13 at 19:49
Understood, that makes sense. Though the other services should be up in the background anyway. I'm surprised that you're using a rolling release system as a server. But arch is pretty great. – nerdwaller Jan 26 '13 at 23:27

By default, getty@.service is of type "idle", which means it'll be started only when systemd's job queue empties for the first time. Unfortunately, the conditions for turning off the status display are not quite the same – the latter happens only when default target starts, but the job queue often runs empty before that.

On slower systems, another cause for this might be that "idle" has a timeout of two seconds, after which getty is started anyway, even if the system is still booting.

As a workaround, you can make getty's service unit tell systemd to turn off status display immediately. Copy the following to /etc/systemd/system/getty@.service:

.include /usr/lib/systemd/system/getty@.service

ExecStartPre=/bin/kill -s RTMIN+21 1
ExecStopPost=/bin/kill -s RTMIN+20 1
share|improve this answer
Didn't work: kernel panicked; had to restore previous snapshot – George K. Jan 26 '13 at 18:41
If changes to systemd units cause a kernel panic, you're making the wrong changes. – grawity Jan 26 '13 at 19:28
Ok, I did two things. I first created /etc/systemd/system/getty@.service and put in the changes above, and that didn't fix it. I then saw that there was a folder under the same directory, and there was a getty@tty1.service in there, and appended the lines above to that file, and that's when the kernel panicked and I had to roll back. What do you think? – George K. Jan 26 '13 at 19:36

You should edit your /etc/systemd/system/ on the line which starts with After=...

Change it to:


share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .