You are not logged in.
Hi,
I have recently just upgraded to 4.12.10-1 (as a side note, thanks to all those who post responses and help here, as I have just trawled these boards and seen the ways to peel the onion of an upgrade conflict hell from 4.7 due to ZFS etc., now about done except for...this)
Usable system boot times are now greatly increased, and shutdown times are far faster.
I want to fix the boot time and not mess the shutdown.
Under 4.7:
[Edit] Startup was crisp, with a rapid display of my LXDM login all up in about 15secs
Shutdown was slow. 90seconds with a 60s+ wait before hard drives finally spinning down and system powering off.
Under 4.12.10-1
Startup takes 40+ seconds, most of that time after the kernel sequence appears to finish and the screen goes blank for 30secs or so before my DM splash appears.
Shutdown is very rapid - 3-5 seconds.
The summary is:
Startup finished in 8.049s (firmware) + 835ms (loader) + 4.919s (kernel) + 6.252s (userspace) = 20.057s
My systemd-analyze blame is as follows:
2.830s systemd-udev-settle.service
1.525s docker.service
1.221s zfs-import-cache.service
801ms dev-sda2.device
535ms systemd-journal-flush.service
507ms systemd-udevd.service
475ms systemd-sysctl.service
313ms polkit.service
292ms zfs-mount.service
201ms systemd-fsck@dev-disk-by\x2duuid-e46e3f00\x2d384e\x2d499d\x2d88f0\x2d5e51cd667e5e.service
151ms systemd-timesyncd.service
138ms media.1.2.mount
131ms media.1.1.mount
119ms systemd-fsck@dev-disk-by\x2duuid-0bcea991\x2d9d8e\x2d4db1\x2d8c77\x2dec554dd1a564.service
59ms NetworkManager.service
50ms systemd-fsck@dev-disk-by\x2duuid-2B3B\x2d2219.service
47ms systemd-fsck@dev-disk-by\x2duuid-ecd0bc7d\x2d9452\x2d477e\x2d8756\x2d7c677ae9c7d6.service
40ms systemd-udev-trigger.service
36ms systemd-modules-load.service
35ms systemd-rfkill.service
35ms systemd-journald.service
27ms systemd-logind.service
23ms user@1000.service
15ms boot.mount
15ms systemd-tmpfiles-setup-dev.service
12ms systemd-tmpfiles-setup.service
10ms wpa_supplicant.service
7ms zfs-share.service
6ms systemd-backlight@backlight:acpi_video0.service
6ms home.mount
5ms dev-mqueue.mount
5ms dev-hugepages.mount
5ms alsa-restore.service
5ms tmp.mount
4ms systemd-random-seed.service
4ms docker.socket
4ms systemd-update-utmp.service
4ms sys-kernel-debug.mount
4ms kmod-static-nodes.service
4ms systemd-remount-fs.service
2ms systemd-user-sessions.service
1ms sys-fs-fuse-connections.mount
1ms sys-kernel-config.mount
And my critical path is:
graphical.target @6.252s
└─multi-user.target @6.252s
└─docker.service @4.726s +1.525s
└─network-online.target @4.725s
└─network.target @4.723s
└─wpa_supplicant.service @5.624s +10ms
└─basic.target @4.640s
└─sockets.target @4.640s
└─docker.socket @4.635s +4ms
└─sysinit.target @4.634s
└─systemd-timesyncd.service @4.482s +151ms
└─systemd-tmpfiles-setup.service @4.468s +12ms
└─local-fs.target @4.466s
└─var-lib-docker-overlay2.mount @5.999s
└─dev-sda2.device @53ms +801ms
My total Kernel time is getting faster - immed after upgrade 8 secs, now under 5secs, and my user space is around 6secs, BUT I do not get a display visible until 30s or more AFTER the ASCII kernel boot sequence is past.
To be clear, after the kernel sequence, it is over 30 seconds before I see the DM login.
I am using i3 TWM via XFCE DM for logon. I have a 4K monitor.
I took the default choices when performing the pacman -Syu upgrade, except for tty related items - I had to turn off tty-dejavue to stop a conflict, that is about it.
Nvidia elements were involved IIRC, but I do not have the screenshots of those choices.
Graphics card is a GTX-970...Nvidia.
The other change was to switch to zfs-dkms, as I wanted to reduce the pain of kernel version dependencies, which got me into a place where I was still on 4.7!
Looking at the numbers, zfs does not seem the culprit.
I have also noticed that i3 no longer scales the terminal fonts for the 4K screen. I now have to increase the default font size.
This makes me think this is somehow a display driver issue.
Audio did not break this time (a first!) and Youtube and media playback is not choppy, which again is nice, as this is normally a pain to resolve.
Any thoughts on how I could find out or fix would be greatly appreciated.
Last edited by timbeauhk (2017-09-09 03:13:16)
Offline
Have you tried running the Nvidia daemon on startup?
You can look here for clarification:
https://wiki.archlinux.org/index.php/Im … ot_process
Starting a Service as early as possible may decrease the boot time.
For the Nvidia daemon it would be:
systemctl enable nvidia-persistenced.service
Offline
Any thoughts on how I could find out or fix would be greatly appreciated.
First, I think you are going to need to be much more clear/precise. We only know what you tell us, and what you are telling us doesn't make much sense:
I am using i3 TWM via XFCE DM for logon.
That's just word-salad of a bunch of WM-related names - I have no idea what to make of that. i3 is a window manager, TWM is a different window manager - which one are you using? XFCE is a desktop environment with it's own window manager ... but it doesn't even have a display manager, so you can't use "XFCE DM for logon."
I had to turn off tty-dejavue to stop a conflict, that is about it.
What does this mean? What was the conflict? What did you turn off and how did you turn it off?
If you want to narrow down if a problem may be with your WM or with your graphics driver, change one of them and observe the result. It's likely easier to change WMs - just boot into another WM a few times and see how it goes.
Last edited by Trilby (2017-09-07 16:21:37)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Well, that font update (tty-dejavu) required a forced upgrade. It was in the news section some time ago. Thats the conflict he is talking about.
But i also didn't get what he meant with his wm configuration. However, you can start xfce with a dm. It would be interesting to know which one is being used.
Offline
Correction: it is LXDM that is my display manager, which I use for login, with i3 as my TWM (tiling window manager) - it was rather late, and my config is a couple of years old.
I enabled the nvidia persistenced service.
I also disabled docker for now to take it out of the equation.
I was still waiting 40s AFTER the boot sequence finishes and the screen goes blank before I see my login window.
So I did, as RoniBoni advised,
pacman -S tty-dejavu --force
This has cured the delay. Many thanks for your awareness, RoniBoni.
I did rather suspect this was going to be the case once I saw how long the forced upgrade took to build the font cache - maybe each boot has to rebuild the fonts before it would be able to throw up the login screen.
Offline