Nunca imaginei que isso algum dia seria possível, mas o tempo de inicialização do Linux está 3x maior que a do Windows em um SSD!
Só para ilustrar, o Windows 10 já roda nesse SSD a mais de 6 meses e possui inúmeros programas/jogos instalados, antivírus, programa torrent, dentre outros programas iniciando junto com o sistema e mesmo assim gasta 1/3 do tempo de inicialização do Linux!
A distribuição Linux nesse caso é o KDE Neon 5.22.4 (recém instalado), com todas as atualizações aplicadas e sem nenhuma modificação/personalização no sistema, totalmente default, apenas instalei o Grub Customizer!
Parece que o grande vilão por trás disso é o processo udisks2.service que está levando mais de 36 segundos para iniciar e pelo que parece o comum é algo na casa dos 800 milissegundos!
Porém não faço a mínima ideia do que fazer para corrigir isso, por isso venho pedir a ajuda dos colegas…
Abaixo um relatório detalhado:
d3xt3r@d3xt3r-neon:~$ systemd-analyze
Startup finished in 16.785s (kernel) + 39.104s (userspace) = 55.890s
graphical.target reached after 39.082s in userspace
d3xt3r@d3xt3r-neon:~$ systemd-analyze blame
36.308s udisks2.service
3.686s dev-sdc5.device
1.587s accounts-daemon.service
1.545s networkd-dispatcher.service
1.493s snapd.service
1.327s smartmontools.service
1.263s systemd-journal-flush.service
964ms avahi-daemon.service
959ms NetworkManager.service
934ms apt-daily.service
841ms polkit.service
708ms ModemManager.service
669ms systemd-logind.service
651ms systemd-resolved.service
631ms wpa_supplicant.service
617ms thermald.service
595ms alsa-restore.service
450ms upower.service
409ms grub-common.service
377ms systemd-udevd.service
369ms packagekit.service
351ms apparmor.service
340ms e2scrub_reap.service
328ms gpu-manager.service
302ms keyboard-setup.service
281ms rsyslog.service
256ms systemd-udev-trigger.service
238ms pppd-dns.service
220ms systemd-timesyncd.service
207ms user@1000.service
207ms systemd-modules-load.service
205ms plymouth-quit-wait.service
199ms systemd-journald.service
197ms plymouth-quit.service
109ms dev-hugepages.mount
108ms dev-mqueue.mount
108ms systemd-sysctl.service
107ms sys-kernel-debug.mount
105ms sys-kernel-tracing.mount
101ms lvm2-monitor.service
95ms neon-configure-inotify.service
86ms kmod-static-nodes.service
86ms blk-availability.service
82ms grub-initrd-fallback.service
80ms snapd.seeded.service
79ms systemd-remount-fs.service
70ms plymouth-start.service
68ms ufw.service
63ms systemd-update-utmp.service
61ms snapd.apparmor.service
51ms plymouth-read-write.service
50ms systemd-random-seed.service
37ms systemd-tmpfiles-setup.service
36ms console-setup.service
32ms systemd-tmpfiles-setup-dev.service
24ms sys-kernel-config.mount
21ms rtkit-daemon.service
21ms sys-fs-fuse-connections.mount
19ms systemd-sysusers.service
18ms systemd-user-sessions.service
15ms user-runtime-dir@1000.service
11ms systemd-update-utmp-runlevel.service
9ms setvtrgb.service
8ms tmp.mount
5ms snapd.socket
d3xt3r@d3xt3r-neon:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @39.082s
└─udisks2.service @2.773s +36.308s
└─basic.target @2.396s
└─sockets.target @2.395s
└─snapd.socket @2.390s +5ms
└─sysinit.target @2.382s
└─systemd-timesyncd.service @2.161s +220ms
└─systemd-tmpfiles-setup.service @2.112s +37ms
└─systemd-journal-flush.service @847ms +1.263s
└─systemd-journald.service @647ms +199ms
└─systemd-journald.socket @636ms
└─system.slice @633ms
└─-.slice @633ms