[opensuse-factory] Graphical Enhancements on openSUSE(?)
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
Citeren Marco Calistri <mcalistri@hotmail.com>:
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
Il 04/11/2017 10:48, Arjen de Korte ha scritto:
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
On Sat, 04 Nov 2017 13:48:01 +0100, Arjen de Korte <suse+factory@de-korte.org> wrote:
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/
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:
$ 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 <mrmazda@earthlink.net> wrote:
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/
Il 04/11/2017 10:48, Arjen de Korte ha scritto:
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
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
Il 05/11/2017 18:28, Felix Miata ha scritto:
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
-----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, 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-----
Il 05/11/2017 20:26, Carlos E. R. ha scritto:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.21.1711060005450.15643@minas-tirith.valinor> El 2017-11-05 a las 22:46 -0000, Marco Calistri escribió:
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-----
Il 05/11/2017 21:06, Carlos E. R. ha scritto:
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
Citeren Marco Calistri <mcalistri@hotmail.com>:
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.
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.
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
Am Montag, den 06.11.2017, 13:07 +0100 schrieb Arjen de Korte:
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
Il 06/11/2017 10:07, Arjen de Korte ha scritto:
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" :-)
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 Content-ID: <alpine.LSU.2.21.1711061436390.22882@Telcontar.valinor> On Monday, 2017-11-06 at 12:56 -0000, Marco Calistri wrote:
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.
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.
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-----
Carlos E. R. schrieb:
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�����Ǩ�
On Mon, 2017-11-06 at 16:07 +0100, Robert Kaiser wrote:
this sounds a lot like https://bugzilla.opensuse.org/show_bug.cgi?id=779928 Cheers Dominique
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 16:14 +0100, Dominique Leuenberger / DimStar wrote:
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-----
Carlos, On Mon, 06 Nov 2017, 16:45:45 +0100, Carlos E. R. wrote:
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
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' 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 Mon, 06 Nov 2017, 18:34:12 +0100, Bruno Friedmann wrote:
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.
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
On lundi, 6 novembre 2017 18.58:41 h CET Manfred Hollstein wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-06 a las 17:24 +0100, Manfred Hollstein escribió:
I mean fixed, static, configured as such in Linux.
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 16:07, Robert Kaiser ha scritto:
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
On 06/11/17 07:07 AM, Arjen de Korte wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 08:22 -0500, Anton Aylward wrote:
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.
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
Il 06/11/2017 11:22, Anton Aylward ha scritto:
I've saved an html and a SVG output plot, I will review as soon as possible
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
Il 06/11/2017 12:33, Marco Calistri ha scritto:
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
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
Il 06/11/2017 12:33, Marco Calistri ha scritto:
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
On 05/11/17 05:26 PM, Carlos E. R. wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-05 a las 20:23 -0500, Anton Aylward escribió:
Indeed. 13.976 seconds on this laptop.
- apparmor
Not here.
- the fsck on the ext4 volumes!
Ocassionally, can't be helped.
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-----
On 05/11/17 09:39 PM, Carlos E. R. wrote:
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 08:08 -0500, Anton Aylward wrote:
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-----
On 04/11/17 07:57 AM, Marco Calistri wrote:
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
Il 04/11/2017 10:50, Anton Aylward ha scritto:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2017-11-04 at 12:56 -0000, Marco Calistri 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. 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat 04 Nov 2017 04:03:36 PM CDT, Jan Engelhardt wrote:
-- 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
Carlos E. R. wrote:
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.
On Sat, 2017-11-04 at 15:43 +0100, Carlos E. R. wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 15:09 +0100, Dominique Leuenberger / DimStar wrote:
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.
:-)) Right. So it is not about speed, but about what each one likes.
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
Il 06/11/2017 12:09, Dominique Leuenberger / DimStar ha scritto:
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 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
-------- 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(?)
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
Citeren Marco Calistri <mcalistri@hotmail.com>:
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
Il 04/11/2017 10:48, Arjen de Korte ha scritto:
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
On Sat, 04 Nov 2017 13:48:01 +0100, Arjen de Korte <suse+factory@de-korte.org> wrote:
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/
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:
$ 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 <mrmazda@earthlink.net> wrote:
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/
Il 04/11/2017 10:48, Arjen de Korte ha scritto:
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
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