You are not logged in.
If I switch to a virtual console, I see a blinking underscore for about 4 seconds until the login prompt is finally displayed. After logging out, it again takes about 4 seconds of blinking for the new login prompt to appear.
This only affects one of my Arch installations, the other one on a much slower computer shows the prompts instantly. I am unaware of any changes I have done to cause this.
Enabling a getty service, e.g. getty@tty2.service, will cause the prompt to be ready immediately after boot without delay but after logging in and out it will have the same delay.
Setting NAutoVTs=6 in /etc/systemd/logind.conf has no effect.
Only this getty service is enabled:
.
├── getty.target.wants
│ └── getty@tty1.service -> /usr/lib/systemd/system/getty@.serviceWhat could be causing this?
Last edited by Markus00000 (2016-10-11 17:50:34)
Offline
Sounds like a videodriver that has trouble switching between X and console mode.
Are you booting to graphical.target / display manager ?
If so, does this happen also if you boot directly to console / multi-user.target ( use kernel parameter "systemd.unit=multi-user.target" on boot ) ?
What videocard and driver are you using ?
Last edited by Lone_Wolf (2016-10-11 14:17:39)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks for replying.
The delay also occurs when no X is involved. Booting to console and switching TTYs is enough to cause it.
Intel HD 4000 with xf86-video-intel.
Offline
For instant console switching with a Haswell card, I would recommend enabling an early KMS start.
Jin, Jîyan, Azadî
Offline
I booted the current Arch ISO and console switching was instant. So, what in my installation could cause this?
@Head_on_a_Stick Considering that it takes more than 4 seconds while being instant on the live ISO and on all distributions I have ever booted, I am not sure why it should suddenly require KMS to launch a TTY within a reasonable amount of time.
Offline
Is there anything printed to the journal during the pause?
Jin, Jîyan, Azadî
Offline
Thanks for making me take a closer look at the journal.
I had to temporarily swap the (non-system) HDD in this laptop. As it is only temporary, the mount point is still in /etc/fstab. As expected systemd informs about the failed mount during boot and writes corresponding journal entries.
What I had not noticed before is that this is happening for each TTY initialization, no matter how long the system has been running already. systemd waits for the drive to mount for 5 seconds as set in my /etc/fstab and only then shows the prompt.
The timeout obviously disappears when I remove the mount point.
Can anyone explain why this happens? Why would it wait for a mount point that failed during boot again and again?
Offline
It may have to do with mount options you use, like systemd-automount .
please post /etc/fstab and "findmnt /whatever/the/mountpoint/for/this/drive/is"
(the findmnt is there to verify the options in fstab are actually in use and not overridden somewhere)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I would be surprised if it were not the mount options considering the delay matches the timeout. I just wonder why it would wait for the drive during each and every TTY initialization instead of only during boot.
/etc/fstab
----------
UUID=<uuid> /media/data xfs rw,nofail,x-systemd.device-timeout=5 0 2# findmnt /media/data
TARGET SOURCE FSTYPE OPTIONS
/media/data /dev/sda3 xfs rw,relatime,attr2,inode64,noquotaI have looked at “man systemd.mount” but did not find an explanation.
Last edited by Markus00000 (2016-10-14 06:54:13)
Offline