Linux demorando 3x mais que o Windows para iniciar em um SSD!

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! :scream:

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

Lvm2 se não estiver usando
Udisk2
Entre outros são os vilões
Serviços de logs e etc…

Tem tempo que não vejo este tópico, mas pode ajudar

O problema é que as distros são configuradas para um uso no geral, e muitos serviços não são necessários e nem utilizados pela maioria das pessoas

1 curtida

Uma distro e um processo que está rápida num Compaq CQ40 (com SSD) é o Bodhi Linux (com ambiente BSPWM) e usando apps em AppImage.

Ele tá ligando em ~5s.

1 curtida