Il 04/11/2017 10:48, Arjen de Korte ha scritto:

Citeren Marco Calistri :

...

Hello,

I have a really personal idea which inducts me to say that current openSUSE has scarce cares of its graphical boot and more in general also for its system sounds if we compare it with other operating systems, including commercial ones.

To make an example regarding the current openSUSE grub/splash-boot, I define it very crude and minimalist. (without offenses for anybody).

Would like to know if somebody of the development team has not yet thought at least one time, to enhance this section.

I've installed from several months now, a custom boot splash which you can find here if you are interested to test it:

https://www.gnome-look.org/p/1009533/

and which offers, *IMHO*, much better graphical experience when booting openSUSE (sorry for my bad quality video):

https://www.youtube.com/watch?v=rfxl7ewF03A

Man, that boot process takes forever. On my four years old laptop, it's under ten seconds until the login prompt appears and I couldn't care less about the graphics up to that point. I think you need to install an SSD instead... :-)

Yes, the boot duration is not "super-sonic" with my hardware but I was not talking about speed here! Regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171101 Kernel: 4.13.10-3.gac5ac24-default - Cinnamon 3.6.0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 04/11/2017 10:50, Anton Aylward ha scritto:

On 04/11/17 07:57 AM, Marco Calistri wrote:

...

Hello,

I have a really personal idea which inducts me to say that current openSUSE has scarce cares of its graphical boot and more in general also for its system sounds if we compare it with other operating systems, including commercial ones.

To make an example regarding the current openSUSE grub/splash-boot, I define it very crude and minimalist. (without offenses for anybody).

I *like* it "crude and minimalist". I want the basic prompt, the GUI version of what I get as a text login. Don't distract me with graphics. Don't distract me with animation. I don't want to spend any more of my life doing login/identification/authentication than I absolutely have to. Get logged in PDQ and get on with Real Work.

I *like* it that in Firefox I have a plug-in the 'remembers' my passwords and fills them in. Password managers are GOOD.

Security is nice. Good security is very nice. But security that distracts you, gets in the way of work, is BAD. People will find ways round it. Security should be as *UN*-intrusive as possible. Dressing it up makes it too obvious, too distracting, too intrusive.

Some people have automatic GUI login enabled. Combined with the automatic application login in Firefox, that seems a disaster to me.

I like Linux 'cos I can have things *convenient and minimalistic* with little trouble.

I'm respectful of your ideas but I don't share them with you integrally, just the ones related to security but once again I was not talking about security here. -- Marco Calistri Linux version : openSUSE Tumbleweed 20171101 Kernel: 4.13.10-3.gac5ac24-default - Cinnamon 3.6.0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 2017-11-04 12:57, Marco Calistri wrote:

To make an example regarding the current openSUSE grub/splash-boot, I define it very crude and minimalist. (without offenses for anybody).

I like crude and minimalist -- a bootloader is just a program that deters me from my standard desktop; it's already taking up about 7% (1s of 14s) of my entire boot time, I don't need it waste more time with painting penguins on the screen. :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2017-11-04 at 12:56 -0000, Marco Calistri wrote:

Il 04/11/2017 10:50, Anton Aylward ha scritto:

...

On 04/11/17 07:57 AM, Marco Calistri wrote:

...

Hello,

I have a really personal idea which inducts me to say that current openSUSE has scarce cares of its graphical boot and more in general also for its system sounds if we compare it with other operating systems, including commercial ones.

To make an example regarding the current openSUSE grub/splash-boot, I define it very crude and minimalist. (without offenses for anybody).

I *like* it "crude and minimalist". I want the basic prompt, the GUI version of what I get as a text login. Don't distract me with graphics. Don't distract me with animation. I don't want to spend any more of my life doing login/identification/authentication than I absolutely have to. Get logged in PDQ and get on with Real Work.

I *like* it that in Firefox I have a plug-in the 'remembers' my passwords and fills them in. Password managers are GOOD.

Security is nice. Good security is very nice. But security that distracts you, gets in the way of work, is BAD. People will find ways round it. Security should be as *UN*-intrusive as possible. Dressing it up makes it too obvious, too distracting, too intrusive.

Some people have automatic GUI login enabled. Combined with the automatic application login in Firefox, that seems a disaster to me.

I like Linux 'cos I can have things *convenient and minimalistic* with little trouble.

I'm respectful of your ideas but I don't share them with you integrally, just the ones related to security but once again I was not talking about security here.

What they are saying is that they do not want a graphical boot. Same for me, I disable the current graphical boot and have a pure text boot on all my machines. There are people that like a graphical boot, but none of those has commented yet on your idea. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln90f0ACgkQtTMYHG2NR9WoBQCeKjkaVHIWsvMKtRoiE9GpTGex 0UQAoJECLe6IGxCb/+orFRj35/bKtHbl =sLAn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 2017-11-04 15:43, Carlos E. R. wrote:

...

Same for me, I disable the current graphical boot and have a pure text boot on all my machines.

Now I feel strangely motivated to make GRUB even stop showing the menu.

I mean come on, the BIOS vendors know to implement "Press F12 to see the full menu", why doesn't GRUB. Hi I do that on all my machines.... set to zero, hide, remove all the

On Sat 04 Nov 2017 04:03:36 PM CDT, Jan Engelhardt wrote: plymouth stuff and rebuild initrd... -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.90-18.32-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 12:31, 1 user, load average: 5.66, 1.70, 0.89 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

H.Merijn Brand composed on 2017-11-04 14:00 (UTC+0100):

On Sat, 04 Nov 2017 13:48:01 +0100, Arjen de Korte wrote:

...

Man, that boot process takes forever. On my four years old laptop, it's under ten seconds until the login prompt appears and I couldn't care less about the graphics up to that point. I think you need to install an SSD instead... :-)

100% agree. I have set splash=verbose to true anyway. I want to see what happens and no delay for graphical nonsense (no offense meant to anyone who *does* care). Anything that slow down my boot should be optional and off by default.

$ grep splash /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/nvme0n1p5 splash=verbose quiet showopts plymouth.enable=0"

On all my openSUSEes, all of the following cmdlines are equivalent: showopts root=LABEL=osTW noresume plymouth.enable=0 splash=verbose 3 showopts root=LABEL=osTW noresume plymouth.enable=0 splash=0 3 showopts root=LABEL=osTW noresume plymouth.enable=0 3 IOW, if you *want* any sort of splash you need to specify it. Otherwise, you get the kernel's plain text default of splash not. Note absence of quiet as well. I want to see *everything* in legible text, even though most of it goes by much too fast to absorb. With Plymouth not installed, plymouth.enable=0 isn't required either. If you want tty1 to retain the tail of boot messages instead of changing to an otherwise empty screen with login prompt, the file that the symlink /etc/systemd/system/getty.target.wants/getty@tty1.service points to needs TTYVTDisallocate=no instead of =yes. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 4 Nov 2017 12:39:40 -0400, Felix Miata wrote:

H.Merijn Brand composed on 2017-11-04 14:00 (UTC+0100):

...

On Sat, 04 Nov 2017 13:48:01 +0100, Arjen de Korte wrote:

...

...

Man, that boot process takes forever. On my four years old laptop, it's under ten seconds until the login prompt appears and I couldn't care less about the graphics up to that point. I think you need to install an SSD instead... :-)

...

100% agree. I have set splash=verbose to true anyway. I want to see what happens and no delay for graphical nonsense (no offense meant to anyone who *does* care). Anything that slow down my boot should be optional and off by default.

...

$ grep splash /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/nvme0n1p5 splash=verbose quiet showopts plymouth.enable=0"

On all my openSUSEes, all of the following cmdlines are equivalent:

showopts root=LABEL=osTW noresume plymouth.enable=0 splash=verbose 3 showopts root=LABEL=osTW noresume plymouth.enable=0 splash=0 3 showopts root=LABEL=osTW noresume plymouth.enable=0 3

IOW, if you *want* any sort of splash you need to specify it. Otherwise, you get the kernel's plain text default of splash not. Note absence of quiet as well. I want to see *everything* in legible text, even though most of it goes by much too fast to absorb.

With Plymouth not installed, plymouth.enable=0 isn't required either.

If you want tty1 to retain the tail of boot messages instead of changing to an otherwise empty screen with login prompt, the file that the symlink /etc/systemd/system/getty.target.wants/getty@tty1.service points to needs

TTYVTDisallocate=no

instead of =yes.

Thanks for all additional info -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.27 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

Marco Calistri composed on 2017-11-05 12:58 (UTC-0500):

I made a simple test: disabled graphical boot completely but boot duration is almost the same as when I enable it.

I could see that there is a sort of freezing when kernel arives at the step when outputs "Switch to root..." or something like that.

So for me also by disabling the splash stuff, the result of boot duration is the same, may be my system and HDD are too slow.

No need to guess why it takes the time it takes. Find out where the time is being spent: systemd-analyze blame -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-05 a las 21:58 -0000, Marco Calistri escribió:

Il 05/11/2017 18:28, Felix Miata ha scritto:

...

Marco Calistri composed on 2017-11-05 12:58 (UTC-0500):

...

No need to guess why it takes the time it takes. Find out where the time is being spent:

systemd-analyze blame

Hi,

I was not aware of this command!

Here the result of it:

marco@linux-turion64:~> systemd-analyze blame

8.467s ModemManager.service 8.033s dev-sda5.device 7.061s initrd-switch-root.service 5.233s SuSEfirewall2_init.service 4.846s display-manager.service

5ms systemd-update-utmp-runlevel.service 5ms sys-fs-fuse-connections.mount lines 21-75/75 (END)

I think at first glance I could disable at least ModemManager and Postfix since I don't use these services and seems are taking a lot of time to start.

No, that's wrong thinking. Instead, look at "systemd-analyze critical-chain" to see where are the actual delays. It does not really matter if a service takes half a minute if it doesn't block login, because the rest of the processes are running concurrently. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAln/kAcACgkQja8UbcUWM1w49QD9G3xxn+Cvt0TDfgaqgY+IMJc4 ptEjH71OAwDrDIpLpPoBAJDOdDyZYsnUi7V0Glqc6f525RCaouABTY61R9uoBVEz =V/ci -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2017-11-05 a las 22:46 -0000, Marco Calistri escribió:

...

El 2017-11-05 a las 21:58 -0000, Marco Calistri escribió:

...

Il 05/11/2017 18:28, Felix Miata ha scritto:

...

Marco Calistri composed on 2017-11-05 12:58 (UTC-0500):

Hi Carlos, Follows further results of this issue:

marco@linux-turion64:~> systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character.

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

└─systemd-fsck@dev-disk-by\x2did-ata\x2dSAMSUNG_HM501II_S2PMJ56B607218\x2dpart6.service @14.035s +342ms

└─dev-disk-by\x2did-ata\x2dSAMSUNG_HM501II_S2PMJ56B607218\x2dpart6.device @14.034s

The worse offender is the firewall, 4 seconds. ntpd 1.2, network 2.5, display manager 2. Nothing about disks, you are not reading the info correctly. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAln/mY8ACgkQja8UbcUWM1wH0gD/UE1SjuQiHBKAez0IrTDCDgol PYvDWxqm12yMXJhrpSoA/1yEiuCuIwGWlKeVsDIvJqM+uqVTXoQh8Z3ucfe2w6i2 =bX8/ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-05 a las 20:23 -0500, Anton Aylward escribió:

On 05/11/17 05:26 PM, Carlos E. R. wrote:

...

Instead, look at "systemd-analyze critical-chain" to see where are the actual delays. It does not really matter if a service takes half a minute if it doesn't block login, because the rest of the processes are running concurrently.

It is nice that this highlights critical items.

My blockages are,

- spamd, which is a real killer

Indeed. 13.976 seconds on this laptop.

- apparmor

Not here.

- the fsck on the ext4 volumes!

Ocassionally, can't be helped.

I realise that those are only forced on bad shutdown or after so many boots, but when they do turn up they are really slow. Score a point for ReiserFS and BtrFS at that.

Right. XFS is also fast. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAln/y1EACgkQja8UbcUWM1yKJQD+Loau1KSKGZ2bBGlKoAp3eayF DTTgl59LLO0n/UQvTpoA/3wqh1r+Y04I58dMKRc3MDdtFE4MtVyxNzlu7xBloUCs =pwtj -----END PGP SIGNATURE-----

Citeren Marco Calistri :

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.

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.

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Citeren Marco Calistri :

...

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

Il 06/11/2017 10:07, Arjen de Korte ha scritto: the Linux services!

...

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" :-)

...

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! Best regards, -- Marco Calistri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 08:08 -0500, Anton Aylward wrote:

On 05/11/17 09:39 PM, Carlos E. R. wrote:

...

El 2017-11-05 a las 20:23 -0500, Anton Aylward escribió:

...

On 05/11/17 05:26 PM, Carlos E. R. wrote:

...

Instead, look at "systemd-analyze critical-chain" to see where are the [...]

...

My blockages are,

...

- spamd, which is a real killer

Indeed. 13.976 seconds on this laptop.

I have `-spamd.service @18.981s +13.208s

...

...

- apparmor

Not here.

Yes, it is a security option. Just like having the firewall - or not - is a security option.

I know, I have it enabled and running. But it is not in the boot critical path. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAX9IACgkQtTMYHG2NR9WUmQCfWvT1iq/JgeLMC/dKeDubior8 1c4An1ziomwdE8o38Ob+wIv3vQNjtjg1 =OlKA -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Monday, 2017-11-06 at 12:56 -0000, Marco Calistri wrote:

...

Citeren Marco Calistri :

...

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

Il 06/11/2017 10:07, Arjen de Korte ha scritto: 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-----

On Sat, 2017-11-04 at 15:43 +0100, Carlos E. R. wrote:

I'm respectful of your ideas but I don't share them with you

...

integrally, just the ones related to security but once again I was not talking about security here.

What they are saying is that they do not want a graphical boot.

Same for me, I disable the current graphical boot and have a pure text boot on all my machines.

There are people that like a graphical boot, but none of those has commented yet on your idea.

Just saying, but if you want FAST BOOT, you also don't want terminal outputs - tty is relatively slow Just to show 'how slow' a lot of output can be (yes, this is definitively exagareted and luckily not as much output as any boot would give):

time "find /usr" real 0m7.765s

time find /usr > /dev/null real 0m0.485s

And no, it's not caches, both runs were on 'hot cache'; it's just that printing out the a lot of output costs time. Depending on what graphical mode your system is in to print out boot logs, it might be even slower (or less noticable) So the static graphical boot splash might actually boot faster than a verbose boot log... But that's drifting apart. AS for the OT: I do like graphical boot and am definitively not opposed to nicer things. The linked theme though does not tickle my taste at all - but that's personal taste. If the distribution license permiits, you can even package it as a separate grub theme and ship it in TW (there is also plymouth-theme-breeze, which is probably not very different to the one linked) Cheers Dominique

Il 06/11/2017 11:22, Anton Aylward ha scritto:

On 06/11/17 07:07 AM, Arjen de Korte wrote:

...

...

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.

The first thing that Marco needs to understand is the dependency chain. That's why Carlos pointed to "critical-chain". Ff course that's not the full chain. The critical chain is a one-dimensional slice of the start-up order, which is actually a lot in parallel.

To see it all, you need to use the "plot" option. OH MY!

I've saved an html and a SVG output plot, I will review as soon as possible

The second thing is that yes, there is kernel time, but there is also time in userspace those apps spend initializing, chundling the results of reading those table and caches.

# systemd-analyze time Startup finished in 4.103s (kernel) + 4.227s (initrd) + 32.196s (userspace) = 40.526s

I don't remember now my result of the above command...I will run it again and compare with your. Cheers, -- Marco Calistri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2017-11-06 at 16:07 +0100, Robert Kaiser wrote:

Carlos E. R. schrieb:

...

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.

Ah, good to see that wicked is a problem for others as well. I guess it may wait for some device to start ups that isn't connected or for some DHCP6 or something else that is actually unneeded, I have a similar thing here. Would be interesting if that can be dealt with in some way as wicked needing more than half of the whole startup time isn't nice, esp. if it's waiting for stuff that's not really needed.

this sounds a lot like https://bugzilla.opensuse.org/show_bug.cgi?id=779928 Cheers Dominique

On Mon, 2017-11-06 at 16:45 +0100, Carlos E. R. wrote:

On Monday, 2017-11-06 at 16:14 +0100, Dominique Leuenberger / DimStar wrote:

...

On Mon, 2017-11-06 at 16:07 +0100, Robert Kaiser wrote:

...

Carlos E. R. schrieb:

...

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.

Ah, good to see that wicked is a problem for others as well. I guess it may wait for some device to start ups that isn't connected or for some DHCP6 or something else that is actually unneeded, I have a similar thing here. Would be interesting if that can be dealt with in some way as wicked needing more than half of the whole startup time isn't nice, esp. if it's waiting for stuff that's not really needed.

this sounds a lot like https://bugzilla.opensuse.org/show_bug.cgi?id=779928

Maybe, I do not have IPv6, so an attempt to get an address via dhcp6 will fail.

Not having ipv6 is exactly the problem for that bug - it will wait like 20s to acknwoledge there is no reply Cheers Dominique

Il 06/11/2017 12:09, Dominique Leuenberger / DimStar ha scritto:

On Sat, 2017-11-04 at 15:43 +0100, Carlos E. R. wrote:

...

I'm respectful of your ideas but I don't share them with you

...

integrally, SNIP There are people that like a graphical boot, but none of those has commented yet on your idea.

Just saying, but if you want FAST BOOT, you also don't want terminal outputs - tty is relatively slow

Just to show 'how slow' a lot of output can be (yes, this is definitively exagareted and luckily not as much output as any boot would give):

...

time "find /usr" real 0m7.765s

...

time find /usr > /dev/null real 0m0.485s

And no, it's not caches, both runs were on 'hot cache'; it's just that printing out the a lot of output costs time.

Depending on what graphical mode your system is in to print out boot logs, it might be even slower (or less noticable)

So the static graphical boot splash might actually boot faster than a verbose boot log...

But that's drifting apart. AS for the OT: I do like graphical boot and am definitively not opposed to nicer things. The linked theme though does not tickle my taste at all - but that's personal taste. If the distribution license permiits, you can even package it as a separate grub theme and ship it in TW (there is also plymouth-theme-breeze, which is probably not very different to the one linked)

Cheers Dominique

I have appreciated your feedback as you are one of the main openSUSE contributors, not just because - generally speaking - you are not against the usage of graphical boot, but especially because you have clearly exposed evidences which make easy to understand that the real root cause of a particular problem, sometime could be other than what seems to be. Regards, -- Greatness is a transitory experience. It is never consistent. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On lundi, 6 novembre 2017 17.24:52 h CET Manfred Hollstein wrote:

Carlos,

On Mon, 06 Nov 2017, 16:45:45 +0100, Carlos E. R. wrote:

...

On Monday, 2017-11-06 at 16:14 +0100, Dominique Leuenberger / DimStar wrote:

...

On Mon, 2017-11-06 at 16:07 +0100, Robert Kaiser wrote:

...

Carlos E. R. schrieb:

...

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

[...]

...

Maybe, I do not have IPv6, so an attempt to get an address via dhcp6 will fail.

But IPv4 is a fixed address in my case.

What do you mean with "is a fixed address"? If you'd use BOOTPROTO=static, no wickedd-dhcp4.service should be started in the first place. If, however, you configured your device's MAC address to always receive the same IPv4 address from the router, then it's not a fixed address from the Linux OS point of view.

Cheers.

l8er manfred

Wutt not what I'm seeing on Leap 42.3 with both dual stack active and functionnal. I've all my network card setup as bootproto='static' But both wicked-dhcpv4 and v6 are enabled up and running. As it was an upgrade from 42.1, perhaps its a bug in term of migration. But editing the interface with yast doesn't change the status of wicked-dhcp If someone else see the same, then it a bug to report. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On lundi, 6 novembre 2017 18.58:41 h CET Manfred Hollstein wrote:

On Mon, 06 Nov 2017, 18:34:12 +0100, Bruno Friedmann wrote:

...

On lundi, 6 novembre 2017 17.24:52 h CET Manfred Hollstein wrote:

...

[...]

Wutt not what I'm seeing on Leap 42.3 with both dual stack active and functionnal. I've all my network card setup as bootproto='static'

That's what I have here, too, but only for the network _cards_; the new computer I'm using has a wlan interface in addition, for which the BOOTPROTO is set to "dhcp4", but it is not automatically enabled, i.e. it is off.

...

But both wicked-dhcpv4 and v6 are enabled up and running.

Yeah, I just saw this:

# systemd-analyze blame | grep wicked 3.546s wicked.service 5ms wickedd-dhcp4.service 4ms wickedd-auto4.service 4ms wickedd-dhcp6.service 2ms wickedd.service 2ms wickedd-nanny.service

So, the dhcp services have been started, but as you can see, they don't have a _real_ effect on the boot time.

...

As it was an upgrade from 42.1, perhaps its a bug in term of migration. But editing the interface with yast doesn't change the status of wicked-dhcp

If someone else see the same, then it a bug to report.

I agree, if Carlos doesn't actually use the DHCP mode during boot, there shouldn't be a delay of 20 seconds; this smells like a bug.

Cheers.

l8er manfred

They have an impact here 8.119s wicked.service 38ms wickedd-auto4.service 36ms wickedd-dhcp4.service 35ms wickedd-dhcp6.service 7ms wickedd-nanny.service 5ms wickedd.service I've disabled them now, I will see next reboot how much it took. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2017-11-06 at 20:33 +0000, Marco Calistri wrote:

Before closing down my office I had the luck to find this interesting article:

https://lizards.opensuse.org/2012/07/26/optimizing-a-boot-time-aka-2- second-boot/

I would ask here to more experts people: how in practice we can "Mask" a service to prevent it being started by systemd?

(citing a brief part by the author of the article):

*Making a laptop boot twice more faster*

*So having the complex dependencies of several services in mind, I decided to mask some of them. Masking in systemd world means the service cannot be started using systemd, so it becomes invisible for it. I masked those*

Very curious to try same approach used above on my Tumbleweed :-)

You mask a service using … systemctl mask Cheers Dominique

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-06 a las 17:24 +0100, Manfred Hollstein escribió:

Carlos,

On Mon, 06 Nov 2017, 16:45:45 +0100, Carlos E. R. wrote:

...

On Monday, 2017-11-06 at 16:14 +0100, Dominique Leuenberger / DimStar wrote:

...

On Mon, 2017-11-06 at 16:07 +0100, Robert Kaiser wrote:

...

Carlos E. R. schrieb:

...

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 [...] Maybe, I do not have IPv6, so an attempt to get an address via dhcp6 will fail.

But IPv4 is a fixed address in my case.

What do you mean with "is a fixed address"?

I mean fixed, static, configured as such in Linux.

If you'd use BOOTPROTO=static, no wickedd-dhcp4.service should be started in the first place.

And it isn't. The problem is with the IPv6. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloBCQQACgkQja8UbcUWM1zWIAD/UgN2CrURFPuK0ob7nYXUCoqF RhlYvS876CAQSv0hjr4A/0vg9jx6S9jq+KkXWXftZi6xizmmtLtFHPOLaQNTwing =y+92 -----END PGP SIGNATURE-----

Il 06/11/2017 12:33, Marco Calistri ha scritto:

Il 06/11/2017 11:22, Anton Aylward ha scritto:

...

On 06/11/17 07:07 AM, Arjen de Korte wrote:

...

...

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.

The first thing that Marco needs to understand is the dependency chain. That's why Carlos pointed to "critical-chain". Ff course that's not the full chain. The critical chain is a one-dimensional slice of the start-up order, which is actually a lot in parallel.

To see it all, you need to use the "plot" option. OH MY!

I've saved an html and a SVG output plot, I will review as soon as possible

...

The second thing is that yes, there is kernel time, but there is also time in userspace those apps spend initializing, chundling the results of reading those table and caches.

# systemd-analyze time Startup finished in 4.103s (kernel) + 4.227s (initrd) + 32.196s (userspace) = 40.526s

I don't remember now my result of the above command...I will run it again and compare with your.

Cheers,

-- Marco Calistri

Hello, At first attempt my result for systemd-analyze time has been around 40 s as your. I Googled a bit and encountered an interesting article wrote for Arch: https://wiki.archlinux.org/index.php/Improve_boot_performance_(Italiano) I verified that in my system the Staggered Spin-Up was enabled: Staggered spin-up Some hardware implements staggered spin-up, which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used: dmesg | grep SSS Then I have disabled it by putting the kernel parameter: libahci.ignore_sss=1 into my /etc/default/grub. When I rebooted, I notice an overall boot time duration 7 seconds faster!: marco@linux-turion64:~> systemd-analyze time Startup finished in 3.479s (kernel) + 4.444s (initrd) + 26.041s (userspace) = 33.964s Of course I'm still very far to the "under 10 seconds boot time" but I'm very happy to be achieved this first result. Regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171102 Kernel: 4.13.11-1.g0526da3-default - Cinnamon 3.6.0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org