Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

2 Answers 2

You should edit your /etc/systemd/system/getty.target.wants/getty@.service on the line which starts with After=...

Change it to: After=multi-user.target

or: After=graphical.target

share|improve this answer

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

[Service]
ExecStartPre=/bin/kill -s RTMIN+21 1
ExecStopPost=/bin/kill -s RTMIN+20 1
Type=simple
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 getty.target.wants 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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.