Slow boot

Enrico1989 · 2018-07-15 16:15:08

The first few lines I see on screen after GRUB are the following

  Booting `Arch Linux'
Loading Linux linux ...
Loading initial ramdisk ...

which don't seem to take much time to go away.
Then I see three lines flashing after each other in what seems to be not a short enough time,

starting version 239
[    6.479834] sp5100-tco sp5100-tco: Watchdog hardware is disabled
[    6.579974] kvm: disabled by bios

`systemd-analyze`'s output is

Startup finished in 14.721s (firmware) + 14.123s (loader) + 6.152s (kernel) + 1.616s (userspace) = 36.613s
graphical.target reached after 1.504s in userspace

Last edited by Enrico1989 (2018-07-15 16:20:35)

dockland · 2018-07-15 16:17:40

Enable virtualization in your UEFI/BIOS.

Enrico1989 · 2018-07-15 16:22:11

dockland wrote:

Enable virtualization in your UEFI/BIOS.

Before I do it, is this compatible with having Arch and Win10 in dual boot?

dockland · 2018-07-15 16:32:53

Sure

Enrico1989 · 2018-07-15 16:36:02

Wow, that shaved off about 12 seconds!

Startup finished in 15.347s (firmware) + 1.979s (loader) + 6.155s (kernel) + 1.499s (userspace) = 24.981s
graphical.target reached after 1.499s in userspace

Anyway, the line

sp5100-tco sp5100-tco: Watchdog hardware is disabled

is still there. Maybe it is related to some slowdown of the boot, can't it?

Last edited by Enrico1989 (2018-07-15 16:44:14)

Enrico1989 · 2018-07-15 16:41:54

Since it seems, from other questions, that also these outputs can be useful to undertand where to act, here they are

$ 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 @1.499s
└─lightdm.service @871ms +627ms
  └─systemd-user-sessions.service @865ms +4ms
    └─network.target @864ms
      └─wpa_supplicant.service @904ms +16ms
        └─basic.target @804ms
          └─sockets.target @804ms
            └─dbus.socket @804ms
              └─sysinit.target @802ms
                └─systemd-timesyncd.service @545ms +257ms
                  └─systemd-tmpfiles-setup.service @535ms +9ms
                    └─local-fs.target @534ms
                      └─boot.mount @487ms +46ms
                        └─local-fs-pre.target @486ms
                          └─lvm2-monitor.service @129ms +357ms
                            └─lvm2-lvmetad.service @147ms
                              └─lvm2-lvmetad.socket @128ms
                                └─system.slice @107ms
                                  └─-.slice @107ms
$ systemd-analyze blame 
           627ms lightdm.service
           528ms systemd-logind.service
           357ms lvm2-monitor.service
           257ms systemd-timesyncd.service
           212ms dev-sda7.device
           136ms systemd-journal-flush.service
           104ms accounts-daemon.service
            79ms systemd-udev-trigger.service
            76ms polkit.service
            56ms systemd-journald.service
            54ms connman.service
            47ms user@1000.service
            46ms boot.mount
            33ms home.mount
            31ms systemd-udevd.service
            21ms systemd-binfmt.service
            16ms wpa_supplicant.service
            14ms systemd-remount-fs.service
            13ms systemd-rfkill.service
            13ms sys-kernel-debug.mount
            13ms systemd-update-utmp.service
            12ms systemd-modules-load.service
            12ms kmod-static-nodes.service
            10ms connman-vpn.service
            10ms dev-mqueue.mount
             9ms dev-hugepages.mount
             9ms dev-disk-by\x2duuid-210f0217\x2dbab6\x2d487d\x2db355\x2deb25db00faa4.swap
             9ms systemd-tmpfiles-setup.service
             7ms systemd-tmpfiles-setup-dev.service
             5ms systemd-sysctl.service
             5ms systemd-random-seed.service
             4ms proc-sys-fs-binfmt_misc.mount
             4ms systemd-user-sessions.service
             4ms rtkit-daemon.service
             4ms sys-kernel-config.mount
             2ms tmp.mount

Enrico1989 · 2018-07-15 17:22:22

I'm giving a look at the wiki page to get some hints.

Among other things, it is suggested to run

# systemctl enable upower

since a service (like UPower) will always be started during boot, but if I run `systemctl status upower` the output tells me that UPower service is actually inactive

● upower.service - Daemon for power management
   Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:upowerd(8)

so is it useless to enable it?

One other interesting point at that page is about "staggered spin-up", but it's not clear to me where to put that kernel parameter. At this page I read that The Arch Linux installation medium uses Syslinux for BIOS systems, and systemd-boot for UEFI systems; being mine a UEFI system, I suppose I have to refer to the sytemd-boot section, am I right?

Last edited by Enrico1989 (2018-07-15 17:26:14)

jasonwryan · 2018-07-15 17:26:43

Don't enable services you don't need: that defeats the purpose of speeding up your boot.

You add the kernel parameter to your boot loader: https://wiki.archlinux.org/index.php/Kernel_parameters. You installed your system, so you should know what your boot{loader,manager} is.

If you really want to speed up your boot, remove your DM.

Enrico1989 · 2018-07-15 17:32:32

The page you and I linked mentions the boot menu. What is it? Is it the GRUB screen where I choose which OS to start? If it so, I think I should follow the "GRUB" section of the wiki, but then why shouldn't I refer to the `systemd-boot` section, being my system a UEFI? Please, help me understand this point.

jasonwryan · 2018-07-15 17:39:19

Yes. That option is for editing the kernel line on the fly.

Enrico1989 · 2018-07-15 18:00:26

jasonwryan wrote:

Don't enable services you don't need: that defeats the purpose of speeding up your boot.

Well, this concept is quite clear, but to me (newbie) a service that is now (after boot) inactive, could have been active for some reason during boot, that's why I asked.

jasonwryan wrote:

You installed your system, so you should know what your boot{loader,manager} is.

Sure I know I installed GRUB, but reading systemd-boot for UEFI systems in a wiki where a systemd-boot section exists make me think that maybe there's something more that I have to understand before messing everything up. And, most of all, trial and error (i.e. how I set up my system day by day) surely improves my ability with Linux (and eveything else in life), but doesn't make me a perfect user. I mean, there are things I've done with 100% awareness, some other for which I guessed, or flipped a coin.

Ops, only now I notice that most sections have a couple of bullets for temporary and permanent action. Still, I'd go for permanent action described in the "systemd-boot" section; but I have no file `/boot/loader/entries/arch.conf` (not even the `/boot/loader` directory); so maybe I should go for the "GRUB" section and change `/etc/default/grub`'s line

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet libahci.ignore_sss=1"

have I got it?

jasonwryan wrote:

If you really want to speed up your boot, remove your DM.

I think I'll follow this suggestion of yours.

Last edited by Enrico1989 (2018-07-15 18:04:53)

loqs · 2018-07-15 18:27:00

Improving_performance/Boot_process

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
If it wasn't used during boot, there will be no output.
To disable it, add libahci.ignore_sss=1 kernel parameter.

Did you check if your system is using staggered spin-up before adding the option to disable it?
If your system's boot loader is grub then only follow instructions for grub.

Enrico1989 · 2018-07-16 17:17:03

loqs wrote:

Improving_performance/Boot_process
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
If it wasn't used during boot, there will be no output.
To disable it, add libahci.ignore_sss=1 kernel parameter.
Did you check if your system is using staggered spin-up before adding the option to disable it?
If your system's boot loader is grub then only follow instructions for grub.

Yes, indeed I can see the following

$ dmesg | grep SSS
[    1.510519] ahci 0000:01:00.1: SSS flag set, parallel bus scan disabled

Adding that parameter to the grub config file allows me to reduce boot time by 3 (kernel) seconds,

Startup finished in 14.754s (firmware) + 800ms (loader) + 3.151s (kernel) + 1.697s (userspace) = 20.403s
graphical.target reached after 1.585s in userspace

Last edited by Enrico1989 (2018-07-16 17:38:03)

Enrico1989 · 2019-02-06 20:37:34

jasonwryan wrote:

If you really want to speed up your boot, remove your DM.

Since a few hours ago LightDM got broken I had to revert it to the previous version and it worked. Then I remembered your suggestion, and finally unistalled it.

1 second faster.

Arch Linux

#1 2018-07-15 16:15:08

Slow boot

#2 2018-07-15 16:17:40

Re: Slow boot

#3 2018-07-15 16:22:11

Re: Slow boot

#4 2018-07-15 16:32:53

Re: Slow boot

#5 2018-07-15 16:36:02

Re: Slow boot

#6 2018-07-15 16:41:54

Re: Slow boot

#7 2018-07-15 17:22:22

Re: Slow boot

#8 2018-07-15 17:26:43

Re: Slow boot

#9 2018-07-15 17:32:32

Re: Slow boot

#10 2018-07-15 17:39:19

Re: Slow boot

#11 2018-07-15 18:00:26

Re: Slow boot

#12 2018-07-15 18:27:00

Re: Slow boot

#13 2018-07-16 17:17:03

Re: Slow boot

#14 2019-02-06 20:37:34

Re: Slow boot

Board footer