You are not logged in.
Pages: 1
Hi, I have been using LXDM and XFCE4.
When I boot my system, plymouth (enabled i915 module) starts first. After that, at the time of starting LXDM and auto-login, it waits for ~20 seconds (on an SSD). My lxdm entry doesn't have any delay set up.
If I move my mouse at the time of the delay, the cursor is shown first, and XFCE launches immediately.
When I disable lxdm, and start it from TTY manually, it doesn't take more than a second to start.
What's wrong with the configuration?
Last edited by Sourav (2019-12-06 13:47:05)
Offline
Please post the journal output from a slow boot.
Offline
Output from
systemd-analyze blame# systemd-analyze blame
49.510s systemd-random-seed.service
893ms systemd-logind.service
713ms lvm2-monitor.service
630ms dev-sda2.device
434ms upower.service
337ms udisks2.service
243ms systemd-udevd.service
226ms systemd-journald.service
198ms systemd-timesyncd.service
187ms systemd-modules-load.service
173ms systemd-tmpfiles-setup-dev.service
159ms systemd-journal-flush.service
117ms polkit.service
115ms NetworkManager.service
85ms user@1000.service
76ms zram-setup@zram0.service
75ms zram-setup@zram1.service
71ms systemd-udev-trigger.service
71ms dev-zram1.swap
64ms plymouth-quit-wait.service
64ms dev-zram0.swap
62ms plymouth-start.service
29ms accounts-daemon.service
25ms plymouth-read-write.service
24ms systemd-tmpfiles-setup.service
17ms wpa_supplicant.service
10ms dev-hugepages.mount
10ms user-runtime-dir@1000.service
10ms dev-mqueue.mount
10ms kmod-static-nodes.service
9ms systemd-remount-fs.service
9ms sys-kernel-debug.mount
8ms systemd-sysctl.service
8ms systemd-update-utmp.service
8ms systemd-vconsole-setup.service
7ms systemd-rfkill.service
7ms systemd-user-sessions.service
6ms sys-kernel-config.mount
4ms rtkit-daemon.service
4ms tmp.mount
2ms sys-fs-fuse-connections.mount When I move my mouse, after the boot, the
systemd-random-seed.servicetakes a short time, ~12 seconds
Last edited by Sourav (2019-12-06 13:07:14)
Offline
If your CPU supports it and
lscpu | grep rdrandgives you output, add
random.trust_cpu=onto your kernel parameters, otherwise install and enable haveged service.
Offline
Sourav what kernel version is the system running?
Offline
I have seen this behaviour since the first installation on the SSD, which was about 5 months ago.
Right now my kernel details are:
bash[~] $ cat /proc/version
Linux version 5.3.11-arch1-1 (linux@archlinux) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Tue, 12 Nov 2019 22:19:48 +0000The good news is adding
random.trust_cpu=onsolves the issue! The system boots within 8 - 10 seconds now... Thanks for the help!
Last edited by Sourav (2019-12-06 13:19:34)
Offline
If you updated to 5.4.2 then removed random.trust_cpu=on what is the boot time?
There was a new feature in 5.4 to generate entropy https://git.kernel.org/pub/scm/linux/ke … a1b65db72b
Offline
After upgrading to linux 5.4.2 and removing the random.trust_cpu=true line, I get the same boot time. It's around 8 seconds...
Offline
Thank you for testing that.
Offline
Pages: 1