[opensuse-factory] Graphical Enhancements on openSUSE(?)

Marco Calistri

4 Nov 2017 4 Nov '17

11:57

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 Cheers, -- 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

Show replies by date

Arjen de Korte

4 Nov 4 Nov

12:48

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

Marco Calistri

12:50

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

H.Merijn Brand

13:00

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

...

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

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" -- 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/

Felix Miata

16:39

New subject: [opensuse-factory] Non-GUI boot desirable (was: Graphical Enhancements...)

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

H.Merijn Brand

20:15

New subject: [opensuse-factory] Non-GUI boot desirable (was: Graphical Enhancements...)

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

5 Nov 5 Nov

17:58

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

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. Regards, -- Marco Calistri

Felix Miata

20:28

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

Marco Calistri

21:58

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

...

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

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 4.632s upower.service 4.170s rsyslog.service 4.051s postfix.service 2.880s jexec.service 2.874s NetworkManager.service 2.793s vboxdrv.service 2.792s nscd.service 2.730s mcelog.service 2.724s rc-local.service 2.673s avahi-daemon.service 2.127s systemd-vconsole-setup.service 1.985s polkit.service 1.946s SuSEfirewall2.service 1.775s systemd-tmpfiles-setup-dev.service 1.421s systemd-udevd.service 1.311s systemd-rfkill.service 1.106s systemd-backlight@backlight:acpi_video0.service 1.067s warsaw.service 1.057s dracut-pre-udev.service 813ms systemd-sysctl.service 691ms klog.service 652ms ntpd.service 646ms noip2.service 605ms dev-hugepages.mount 578ms user@485.service 551ms systemd-remount-fs.service 532ms sshd.service 507ms wpa_supplicant.service 491ms systemd-logind.service 480ms systemd-tmpfiles-setup.service 451ms sys-kernel-debug.mount 407ms systemd-fsck@dev-disk-by\x2did-ata\x2dSAMSUNG_HM501II_S2PMJ56B607218\x2dpart6.service 368ms accounts-daemon.service 366ms systemd-backlight@backlight:intel_backlight.service 352ms systemd-journal-flush.service 307ms systemd-journald.service 302ms dev-mqueue.mount 254ms systemd-fsck-root.service 245ms systemd-udev-trigger.service 244ms systemd-user-sessions.service 237ms systemd-random-seed.service 235ms udisks2.service 234ms plymouth-read-write.service 225ms systemd-update-utmp.service 203ms colord.service 198ms kmod-static-nodes.service 161ms systemd-modules-load.service 155ms initrd-parse-etc.service 142ms proc-sys-fs-binfmt_misc.mount 128ms dev-disk-by\x2did-ata\x2dSAMSUNG_HM501II_S2PMJ56B607218\x2dpart7.swap 128ms iscsi.service 94ms vboxautostart-service.service 77ms rtkit-daemon.service 74ms plymouth-start.service 69ms plymouth-switch-root.service 68ms home.mount 64ms user@1000.service 46ms dracut-cmdline.service 33ms dracut-shutdown.service 32ms vboxweb-service.service 26ms tmp.mount 20ms sysroot.mount 18ms dracut-pre-trigger.service 17ms issue-generator.service 14ms vboxballoonctrl-service.service 11ms initrd-cleanup.service 7ms initrd-udevadm-cleanup-db.service 6ms alsa-restore.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. Also the services: dev-sda5.device, initrd-switch-root.service and jexec.service I would like to know what they are doing and then disable them too. 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

Carlos E. R.

22:26

-----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-----

Marco Calistri

22:46

Il 05/11/2017 20:26, Carlos E. R. ha scritto:

...

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

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 marco@linux-turion64:~> sudo journalctl -xb --no-pager|grep SATA [sudo] password di root: nov 05 20:06:55 linux-turion64 kernel: ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x1a impl SATA mode nov 05 20:06:55 linux-turion64 kernel: ata2: SATA max UDMA/133 abar m2048@0xe8c06000 port 0xe8c06180 irq 24 nov 05 20:06:55 linux-turion64 kernel: ata4: SATA max UDMA/133 abar m2048@0xe8c06000 port 0xe8c06280 irq 24 nov 05 20:06:55 linux-turion64 kernel: ata5: SATA max UDMA/133 abar m2048@0xe8c06000 port 0xe8c06300 irq 24 nov 05 20:06:55 linux-turion64 kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) nov 05 20:06:55 linux-turion64 kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) nov 05 20:06:55 linux-turion64 kernel: ata5: SATA link down (SStatus 0 SControl 300) marco@linux-turion64:~> cat /etc/fstab /dev/disk/by-id/ata-SAMSUNG_HM501II_S2PMJ56B607218-part7 swap swap defaults 0 0 /dev/disk/by-id/ata-SAMSUNG_HM501II_S2PMJ56B607218-part5 / ext4 acl,user_xattr,noatime 1 1 /dev/disk/by-id/ata-SAMSUNG_HM501II_S2PMJ56B607218-part6 /home ext4 defaults,noatime 1 2 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 (I have some doubts about correctness of parameters I used for my root partition. Regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171102 Kernel: 4.13.11-1.g0526da3-default - Cinnamon 3.6.0

Carlos E. R.

23:06

-----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-----

Marco Calistri

6 Nov 6 Nov

10:41

Il 05/11/2017 21:06, Carlos E. R. ha scritto:

...

Content-ID:

El 2017-11-05 a las 22:46 -0000, Marco Calistri escribió:

...
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))

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. 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! 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 :-/ 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? Saludos, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171102 Kernel: 4.13.11-1.g0526da3-default - Cinnamon 3.6.0

Arjen de Korte

12:07

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

Oliver Neukum

12:37

Am Montag, den 06.11.2017, 13:07 +0100 schrieb Arjen de Korte:

...

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.

Hi, though even if they wait for disk a lot, what do they read? Too many small config files? Too many possible locations? This is worth investigating. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marco Calistri

12:56

...

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

Carlos E. R.

13:48

-----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-----

Robert Kaiser

15:07

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. Cheers, KaiRo N��r��y隊Z)z{.��r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��r�+��0��Ǩ�

Dominique Leuenberger / DimStar

15:14

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

Carlos E. R.

15:45

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. But IPv4 is a fixed address in my case. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAg7AACgkQtTMYHG2NR9V92ACfYBQ7lL99w3wdqzn94QlWZ2hR nZQAnA6CbrJXLom8Nn8HA0VKey4gfNNI =nhe+ -----END PGP SIGNATURE-----

Dominique Leuenberger / DimStar

16:15

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

Manfred Hollstein

16:24

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

Bruno Friedmann

17:34

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

Manfred Hollstein

17:58

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

Bruno Friedmann

20:16

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

Carlos E. R.

7 Nov 7 Nov

01:14

-----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-----

Daniele

6 Nov 6 Nov

16:51

Il 06/11/2017 16:07, Robert Kaiser ha scritto:

...

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.

Yes wicked is a pain, like apparmor: Old system (core 2 duo with HDD): graphical.target @21.649s └─wicked.service @11.284s +7.797s └─wickedd-nanny.service @11.255s +27ms └─wickedd.service @11.138s +116ms └─wickedd-auto4.service @10.404s +732ms TW on a newer system (Athlon 860k with a slow HDD): graphical.target @57.559s └─wicked.service @29.161s +12.257s └─wickedd-nanny.service @28.703s +455ms └─wickedd.service @28.175s +526ms └─wickedd-auto4.service @25.805s +2.368s └─dbus.service @24.593s └─basic.target @24.591s └─paths.target @24.591s └─cups.path @24.591s └─sysinit.target @24.545s └─apparmor.service @1.827s +22.717s In both system ipv6 disable in Yast Bye, Daniele -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

13:22

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

Carlos E. R.

13:52

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

...

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.

Right. The critital path looks at what causes delays. Where the process is actually waiting for those to finish, can't continue.

...

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

Yes.

...

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

cer@Telcontar:~> systemd-analyze time Startup finished in 1.931s (kernel) + 4.197s (initrd) + 1min 4.194s (userspace) = 1min 10.322s And I boot to text mode with no grahics at all! And I have an SSD! And I don't care. :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAaS0ACgkQtTMYHG2NR9VXvgCfWZDXJKpgIPuOAFCvvTV7RDBn i0sAn2RgeH96UHqHH4pYhlIorrsHN/kd =+Xqn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marco Calistri

14:33

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

Marco Calistri

20:33

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

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

Dominique Leuenberger / DimStar

20:40

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

Marco Calistri

7 Nov 7 Nov

14:37

Il 06/11/2017 18:40, Dominique Leuenberger / DimStar ha scritto:

...

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

Thanks! Regards, -- Marco Calistri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Anton Aylward

6 Nov 6 Nov

21:32

On 06/11/17 03:33 PM, Marco Calistri wrote:

...

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

You are going to have to determine not only what is both necessary and sufficient, but on what they depend. Arbitrarily masking off services at boot (rather than making the dependent, say, on a user logging in[1]) might mean your machine does not actually come up in a serviceable manner. I have directories under /home/anton/ that are mountable file systems. Strictly speaking they don't need to be mounted at boot time. Some day I'll figure out how to use the PAM module to only mount them when I log in :-) If anyone is using pam_mount to do local mount using ~/.pam_mount.conf.xml for both text and graphical user login, please email me. [1] The SYSTEM needs basic internal email & logging so you need postfix or exim, and your chosen system logger, but you might have a local dovecot server that only needs to make the local mail store available if and when a user logs in. Whether or not you need to defer the CUPS printing service until a user logs in is a policy decision. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marco Calistri

7 Nov 7 Nov

22:47

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

Anton Aylward

6 Nov 6 Nov

01:23

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 - apparmor - the fsck on the ext4 volumes! 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. -- Our country is now geared to an arms economy bred in an artificually induced psychosis of war hysteria and an incessant propaganda of fear. -- Douglas MacArthur -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

02:39

-----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-----

Anton Aylward

13:08

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.

...

...
- the fsck on the ext4 volumes!

Occasionally, can't be helped.

Indeed.

...

...
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.

This is Linux. We have option. It's options, not turtles, all the way down. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

13:12

-----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-----

Anton Aylward

4 Nov 4 Nov

12:50

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. -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marco Calistri

12:56

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

Carlos E. R.

14:43

-----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

Jan Engelhardt

15:03

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

Malcolm

15:18

New subject: [opensuse-factory] Re: Graphical Enhancements on openSUSE(?)

...

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

Andrei Borzenkov

18:04

04.11.2017 18:03, Jan Engelhardt пишет:

...

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.

See GRUB_TIMEOUT_STYLE=hidden. Or do you miss prompt? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Ströder

16:16

Carlos E. R. wrote:

...

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.

Same here. Sorry to the people who cares about it. But the only thing I'm personally interested in regarding graphical boot is the easiest way to disable it and reliably uninstall all files related to it. I'm not an average user though. But I did install openSUSE Tumbleweed on several average users' laptops. They never asked why the boot process looks not nice. They only care about what happens after login and whether everything works reliably (Firefox, LibreOffice, PDF-Viewer or similar). Ciao, Michael.

Dominique Leuenberger / DimStar

6 Nov 6 Nov

14:09

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

Carlos E. R.

14:19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 15:09 +0100, Dominique Leuenberger / DimStar wrote:

...

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

Ah, yes, that is also true :-) Just run "cat longtxtfile" and compare it to "cat longtxtfile > file"

...

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.

True. And my guess is that it is slower in Linux, because the terminal is a complex abstraction, there is no direct video memory write.

...

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...

:-)) Right. So it is not about speed, but about what each one likes.

...

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)

Good :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAb24ACgkQtTMYHG2NR9XgCACglwZT0M7e1Rll/JltEQfQzLP9 /MIAnjlJmep0DUYk5r8MZmQ0DIsZqsaI =NpbJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marco Calistri

16:41

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

Jan Engelhardt

4 Nov 4 Nov

13:16

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

Marco Calistri

13:56

-------- Original Message -------- From: Jan Engelhardt Sent: Saturday, Nov 4, 2017 11:16 AM GMT-0200 To: Marco Calistri Cc: opensuse-factory Subject: [opensuse-factory] Graphical Enhancements on openSUSE(?)

...

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

I'm getting frustrated instead not by a slow bootloader but by some other daemons as for example tracker, or even app as FireFox hanging on some scripts, which occurr at the worst moment when you are doing something of important, freezing up your system without a valid reason. :-/ But as we know "your mileage may vary". 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

2364

Age (days ago)

2367

Last active (days ago)

List overview

Download

50 comments

16 participants

participants (16)

Andrei Borzenkov
Anton Aylward
Arjen de Korte
Bruno Friedmann
Carlos E. R.
Daniele
Dominique Leuenberger / DimStar
Felix Miata
H.Merijn Brand
Jan Engelhardt
Malcolm
Manfred Hollstein
Marco Calistri
Michael Ströder
Oliver Neukum
Robert Kaiser