-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.1711061436390.22882@Telcontar.valinor> On Monday, 2017-11-06 at 12:56 -0000, Marco Calistri wrote:
Il 06/11/2017 10:07, Arjen de Korte ha scritto:
Citeren Marco Calistri <mcalistri@hotmail.com>:
I was basing my guessing on the first output (systemd-analyze blame ) where the bigger offenders appears to be the sda5 ( root / partition) and Modem-manager. As I wrote, I was not confident of this kind of analysis using systemd.
I'm almost certain, it is the HDD which is the culprit here. Yes, it could be the HDD. I didn't mentioned that I have W10 in dual boot on this laptop running Tumbleweed and also on W10 boot time is almost the same as in TW, then I cannot think that culprit being some of the Linux services!
No, your disk is not the *culprit*. Of course, if you have a rotating rust disk your system will boot slower than a system with an SSD. So? Just compare times with a machine with a hard disk. Then your times may be normal.
Anyhow, look how we can be confused by ML users feedback which point the slowness of the boot to the splash boot whereas the issue is elsewhere!
See below.
If I would have followed straightly the suggestions passed by some of the users which provided their *"academic hints"*, I should have uninstalled Plymouth and disabled my splash boot uselessly :-/
You're comparing apples to oranges. Those people don't want fancy graphics, because the time to login is already in the order of ten seconds or so. They (like me) simply want to login and start work as fast as possible. Adding a second boot time there *is* relevant. On your system, it takes over a minute before the login prompt appears so I understand bootsplash may be relevant and you'll not notice this. But given the choice, over a minute waiting time with fancy graphics or less than ten seconds without, most people would probably choose the latter.
Disagree with you (in a friendly way of the term of course) because after I posted the video of my customized graphical boot, some users addicted that slowness could be related to the boot splash stuff. Anyhow honestly to me waiting 10 seconds or 120 second to login into my laptop is *totally irrelevant* so I neither insist on this matter. If I would start work as fast as possible I will keep my laptop "always-on" :-)
Which is why you have to look at hard data and not appearances. The time used by the graphical boot display is not considered by systemd analysis, because systemd has not started yet at that point. Me, I do not use a graphical boot simply because I do not like graphical boots, I want to see all the boot messages in text instead. Nothing to do with speed. Notice that a static boot display makes the user think that nothing is happening during boot: why is the computer doing nothing, just a "silly" photo? And if you make the boot picture a moving movie or animation, some people will say that the computer is wasting cycles on displaying that animation instead of booting.
So now I would like to ask: why SuSEfirewall2_init.service, display-manager.service, NetworkManager.service, took so long time to be up and running at least on my system?
I don't know if there is a way to check this, but I highly suspect these services are waiting for disk-I/O. All caches are empty at boot time, so everything has to come from disk. This is where SSD drives with essentially zero seek times shine. Changing to SSD drives has been the single biggest performance improvement on my systems.
It is not neither far of my plans to purchase an SSD just to login in my system in less than 10 seconds, at least for the moment!
Right. No, you have to compare times with other users with similar disks. If you see other people having delays in the same points, then /you/ don't have a problem, but there is a global issue there, which perhaps can not be helped. So, you have to look at this "graph" to see what is actually delaying boot (again, the graphical boot does not enter the consideration): graphical.target @25.566s └─display-manager.service @23.488s +2.075s └─time-sync.target @23.485s └─ntpd.service @22.242s +1.242s └─network.target @22.173s └─NetworkManager.service @19.591s +2.581s └─SuSEfirewall2_init.service @15.517s +4.072s └─sysinit.target @15.513s └─systemd-update-utmp.service @15.476s +36ms └─systemd-tmpfiles-setup.service @14.741s +732ms └─local-fs.target @14.738s └─home.mount @14.445s +292ms So, these are your known hurdles: display-manager.service @23.488s +2.075s ntpd.service @22.242s +1.242s NetworkManager.service @19.591s +2.581s SuSEfirewall2_init.service @15.517s +4.072s Why is the firewall start so slow? I don't know, but I would not blame your disk (none of those are disk intensive). Maybe you are using dhcp. I have seen other users with the same problem posting in the mail list, reason not known. Look, on this desktop I have an SSD, and: └─clamd.service @34.757s +11.407s └─network.target @34.733s └─wicked.service @14.681s +20.046s └─wickedd-nanny.service @14.648s +27ms └─wickedd.service @14.571s +20ms └─wickedd-dhcp4.service @14.498s +61ms └─SuSEfirewall2_init.service @14.171s +250ms └─basic.target @14.121s See "wicked.service @14.681s +20.046s"? That's a huge time. Yet the firewall starts fast. And I'm not going to study this much, I don't really care :-) I do really wonder why clamd is so slow, though. Spamd is very slow to start on my laptop. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAaCMACgkQtTMYHG2NR9XsMgCfRj3oEJcWGiZkKDEglSz2g6QF yBYAn1AC7Atx5/aNvc41ieUy5cI/Pmck =HGka -----END PGP SIGNATURE-----