Como Posso Reduzir Mais o Meu Boot Time?

Opa pessoal, eu tenho o Pop!_Os 21.10 no meu notebook HP de 2012 e que já tá meio usado (sorte que o Linux reviveu ele!) e ele tava com um boot time de 1.40min +ou-, após algumas pesquisas e aprendizados consegui reduzir para 40s +ou-.

Porém vi no meu terminal que ainda tem algumas coisas que parecem ser atrasadas e levar mais tempo que deveria, como eu comecei a usar Linux a apenas 1 mês e ainda estou aprendendo, vim aqui buscar ajuda de alguém mais entendido do assunto que possa me ajudar a descobrir algumas coisas que consiga reduzir o tempo do meu boot.

Segue alguns logs do meu terminal

Log Date: 09/01/2022 - 02:47 GTM-3

[email protected]:~$ systemd-analyze
Startup finished in 10.834s (kernel) + 35.203s (userspace) = 46.038s 
graphical.target reached after 30.682s in userspace

[email protected]:~$ 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 @30.682s
└─multi-user.target @30.681s
  └─libvirt-guests.service @29.952s +728ms
    └─libvirtd.service @21.063s +8.578s
      └─network.target @20.834s
        └─NetworkManager.service @17.371s +3.461s
          └─dbus.service @17.363s
            └─basic.target @17.217s
              └─sockets.target @17.217s
                └─libvirtd-ro.socket @17.216s
                  └─libvirtd.socket @17.213s +3ms
                    └─sysinit.target @17.058s
                      └─systemd-timesyncd.service @16.834s +223ms
                        └─systemd-tmpfiles-setup.service @16.028s +781ms
                          └─systemd-journal-flush.service @5.263s +10.762s
                            └─systemd-remount-fs.service @4.945s +174ms
                              └─systemd-journald.socket @4.726s
                                └─-.mount @4.057s
                                  └─-.slice @4.057s
                                  
[email protected]:~$ systemd-analyze blame
10.762s systemd-journal-flush.service
10.402s udisks2.service
 8.578s libvirtd.service
 7.313s accounts-daemon.service
 5.626s cups.service
 5.093s dev-sda1.device
 4.837s fwupd.service
 4.197s gdm.service
 3.461s NetworkManager.service
 3.201s avahi-daemon.service
 3.198s bluetooth.service
 3.157s system76-power.service
 3.039s gpu-manager.service
 2.987s wpa_supplicant.service
 2.912s switcheroo-control.service
 2.900s thermald.service
 2.894s systemd-logind.service
 2.894s systemd-machined.service
 2.502s systemd-resolved.service
 2.135s [email protected]
 2.044s rsyslog.service
 1.970s tlp.service
 1.798s apparmor.service
 1.465s grub-common.service
 1.389s polkit.service
 1.351s e2scrub_reap.service
 1.220s systemd-modules-load.service
 1.121s resolvconf-pull-resolved.service
 1.110s networking.service
  801ms systemd-udev-trigger.service
  781ms systemd-tmpfiles-setup.service
  728ms libvirt-guests.service
  693ms qemu-kvm.service

Da sua sequencia de boot o que eu removeria se quisesse mais velocidade seria as VMs, o libvirt e o quemu se removidos ajudariam, mas aí vc teria que abrir mão de usar vms.

Agora o que realmente impulsonaria o boot seria usar um SSD. 40 segundos em boot para HD está bom demais.

2 curtidas

O seu notebook fica ligado na tomada o tempo todo? Se sim, o melhor jeito é suspender a sessão, assim quando vc quiser iniciar novamente terá o início em poucos segundos.

1 curtida

O Gnome gasta um tempo considerável para ser carregado, eu também tenho um PC de mais de 20 anos, e as vezes uso SO no HD, sofria muito quando usava o Gnome, depois passei a usar o XFCE melhorou pacas, ai depois usei o LXDE, melhorou um pouco mais e hoje só uso o Gerenciador de janelas “OpenBox” sem O ambiente gráfico.

Para você conseguir um tempo melhor no HD usando o Gnome você teria seguir esse tutorial, bem explicado do site ITSFOSS: Find Out How Long Does it Take To Boot Your Linux System - It's FOSS está em inglês mas você pode traduzir com o google tradutor se desejar!
Já sabendo quanto tempo leva cada processo/serviço você começa a ver com reduzir esse tempo.

[ATUALIZAÇÃO]
Agora que fui clicar você postou um log do SystemD, agora é pegar estes que demoram mais e até compilar ele na sua maquina com patchs de otimização e vale até testar outros kernels.

2 curtidas

Sim, eu faço isso! Ajuda bastante mesmo, porém queria tentar diminuir mais esse tempo para quando eu precisar bootar.

1 curtida

Valeu pelas dicas! No momento to gostando de usar o Pop! como Gnome mesmo. Esse tempo não chega a ser algo tão ruim assim pra mim, ao ponto de precisar trocar de distro. Só se talvez a versão LTS pudesse melhorar esse quadro, mas por enquanto não vejo necessidade.

Eu removi o libvirt como disse já que não usarei VMs nesse meu note e consegui reduzir apenas alguns segundos (total de 44s no momento), infelizmente tem algumas tarefas que estão tendo um grande delay, como mostra na critical-chain. Por exemplo o “journal” ta com 12s de delay pra realizar a tarefa, se não entendi errado. Pesquisei na internet que essa tarefa em questão é uma espécie de log e que não seria ideal removê-lo, porem coloquei pelo menos um limite para guardar até 1 semana de log. Segue abaixo logs do “systemd” e ao final também a quantidade de MB quardada no “journal”.

Logs do Terminal com Systemd & Journalctl

Log Date: 10/01/2022 - 01:10 GTM-3

[email protected]:~$ systemd-analyze
Startup finished in 8.121s (kernel) + 36.516s (userspace) = 44.638s 
graphical.target reached after 32.228s in userspace

[email protected]:~$ 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 @32.228s
└─multi-user.target @32.228s
  └─cups-browsed.service @32.228s
    └─cups.service @27.516s +4.709s
      └─network.target @27.513s
        └─NetworkManager.service @21.313s +6.199s
          └─dbus.service @21.307s
            └─basic.target @21.258s
              └─sockets.target @21.257s
                └─uuidd.socket @21.257s
                  └─sysinit.target @21.069s
                    └─systemd-timesyncd.service @20.998s +70ms
                      └─systemd-tmpfiles-setup.service @19.991s +999ms
                        └─systemd-journal-flush.service @7.763s +12.227s
                          └─systemd-remount-fs.service @7.555s +119ms
                            └─systemd-journald.socket @7.226s
                              └─-.mount @6.591s
                                └─-.slice @6.591s
                                
[email protected]:~$ systemd-analyze blame
12.227s systemd-journal-flush.service
 9.456s udisks2.service
 6.549s accounts-daemon.service
 6.533s fwupd.service
 6.199s NetworkManager.service
 4.813s dev-sda1.device
 4.709s cups.service
 4.517s gpu-manager.service
 3.673s gdm.service
 3.100s systemd-resolved.service
 2.972s [email protected]
 2.842s avahi-daemon.service
 2.841s bluetooth.service
 2.735s system76-power.service
 2.720s e2scrub_reap.service
 2.489s wpa_supplicant.service
 2.423s switcheroo-control.service
 2.414s thermald.service
 2.411s systemd-logind.service
 2.211s rsyslog.service
 2.135s apparmor.service
 1.710s resolvconf-pull-resolved.service
 1.376s apport.service
 1.349s grub-common.service
 1.268s tlp.service
 1.063s systemd-modules-load.service
  999ms systemd-tmpfiles-setup.service
  981ms networking.service
  800ms polkit.service
  792ms qemu-kvm.service
  711ms systemd-udev-trigger.service
  689ms keyboard-setup.service
  660ms grub-initrd-fallback.service
  
[email protected]:~$ journalctl --disk-usage
Archived and active journals take up 240.0M in the file system.

Mas realmente não tá um tempo tão longo assim para um notebook simples e bem usado com apenas um HD.

Legal @EduardoChaves, mas se quiser você pode usar outra interface gráfica sem precisar trocar de Distro, no Pop! OS e Ubuntu é muito fácil. Não sei não, tem que verificar cada pacote, como disse analisar cada processo/serviço separadamente.

Aqui neste site mostra como exportar o depuração para gráfico e vários outros comando uteis: systemd-analyze linux command man page
Está em inglês mas pode traduzir para o português se desejar pelo Google Tradutor.

Tem um guia do OpenSuse que vai servir em qualquer distro que use SystemD aparentemente: O daemon systemd | Guia de Administração | SUSE Linux Enterprise Desktop 15 SP2
Este guia está em português.

2 curtidas

Compilar o kernel para a maquina removendo driver inuteis pode reduzir algum valor mas n espere grandes coisas.

1 curtida

eu desabilitei serviços em segundo plano do systemd, aqueles qualquer-coisa-WAIT-não-me-lembro-o-que, que demoram o boot esperando montagem de dispositivos/pastas em rede, oq n tenho. só aí ganhei uns 10 segundos.

depois mudei do grub para o systemd. ficou mais rápido. não consegui usar o efistub, mais rápido ainda, porque no debian n consegui instalar a chave no UEFI (uso UEFI).

por último, mudei o initramfs-tools, com /etc/initramfs-tools/initramfs.conf de módules=most para modules=list. e no /etc/initramfs-tools/modules coloquei os módulos necessários para o boot inicial, como xfs, i915, nvme e pcieport (os seus serão diferentes). com isso ganhei mais 11 segundos.

para consulta:

(initramfs) [Dica/Tuto] Otimizando initramfs ( Debian) e adicionado Initramfs mínimo( menos 6s no boot em um Celeron®) - 03/09

(systemd-boot) Using systemd-boot on Debian Bullseye

obviamente por SUA conta a risco. :stuck_out_tongue_winking_eye: rsrsrsrs

1 curtida
  • @aguamole: Como eu não tenho muito conhecimento sobre como fazer isso, vou deixar de lado por enquanto, até pra não acabar fazendo besteira no meu OS. Talvez no futuro eu vá atrás de fazer isso kk.

  • @acvsilva:

  1. Nos comandos de “systemd-analyse …” eu não achei nenhum desses -WAIT-.

  2. Fui ver aqui que o meu notebook é Legacy Bios e não é compatível com UEFI, e nesse artigo do ArchWiki diz que o systemd-boot pode não funcionar direito em Bios… No mesmo post ele fala de um outro bootloader chamado Clover, que esse é compatível com Bios, funciona como um ‘emulador de UEFI’ e que eu poderia até mesmo usar o efistub com ele, como explica nesse outro artigo da ArchWiki. Porém é preciso fazer uma EFI System Partition, o que vai chegando em um nível que está acima do meu conhecimento kk. No momento não vou fazer essa troca, quem sabe no futuro eu faça. Até porque eu não queria formatar meu note que acabei de configurar do meu jeito com o meu novo OS que baixei kk.

  3. Fiz as mudanças de acordo com o link que você mandou sobre initramfs e consegui reduzir para uns 35s, depois disso vi que o “run-qemu.mount” tava tomando uns 13seg, fui pesquisar no google como retirar ele e quando tentei remover com “apt-get remove/puerge” falava que não tinha nada a remover, mas que eu poderia remover um chamado “qemu-system-x86”. Removi esse e após reiniciar a notebook, o qemu continua lá e agora voltei pra uns 40s de boot kk, reiniciei de novo e foi pra 38s. Mas enfim tá bom até, já que deixo ele em suspenso e agiliza bastante.

Segue como está agora os meus Logs de Boot:

Log Date: 12/01/2022 - 08:00 GTM-3

Startup finished in 9.027s (kernel) + 29.583s (userspace) = 38.610s
graphical.target reached after 25.569s in userspace

graphical.target ^25.569s
└─udisks2.service ^17.200s +8.368s
└─basic.target ^15.958s
└─sockets.target ^15.958s
└─uuidd.socket ^15.958s
└─sysinit.target ^15.768s
└─systemd-timesyncd.service ^15.531s +236ms
└─systemd-tmpfiles-setup.service ^14.271s +1.234s
└─local-fs.target ^14.265s
└─run-qemu.mount ^14.261s +3ms
└─swap.target ^14.260s
└─dev-mapper-cryptswap.swap ^14.097s +163ms
└─dev-mapper-cryptswap.device ^14.095s

8.368s udisks2.service
7.087s accounts-daemon.service
6.409s com.system76.Scheduler.service
5.219s dev-sda1.device
5.039s systemd-journal-flush.service
4.526s cups.service
3.937s NetworkManager.service
3.591s gdm.service
3.580s avahi-daemon.service
3.577s bluetooth.service
3.307s gpu-manager.service
3.191s networking.service
3.090s system76-power.service
2.702s switcheroo-control.service
2.669s wpa_supplicant.service
2.652s apport.service
2.637s fwupd.service
2.621s thermald.service
2.617s systemd-logind.service
2.279s upower.service
2.256s tlp.service
1.864s rsyslog.service
1.813s grub-common.service
1.674s systemd-resolved.service
1.597s e2scrub_reap.service
1.371s resolvconf-pull-resolved.service
1.234s systemd-tmpfiles-setup.service
1.146s systemd-cryptsetup^cryptswap.service
1.007s apparmor.service
949ms polkit.service
772ms systemd-udevd.service
744ms systemd-udev-trigger.service
602ms keyboard-setup.service

1 curtida

melhor deixar como está. não são uns minutinhos a mais ou a menos que mudarão sua vida no nosso querido isfenicídio. se vc aguentou o boot do windows até hoje, aguenta o nosso. kkkkk

1 curtida

O engraçado é que quando tava no W10 era mais rápido kkk. Mas ainda prefiro o Linux, gostei mto do Pop com o Gnome. Deixou o note mais rápido até… O bom é que eu tenho um desktop de melhor config com ssd e tals, esse note é só pra ser um pc portátil pra mim kk.

1 curtida

Então no meu eu cheguei a conclusão de que n compensa o esforço.

1 curtida

O que o windouws faz quando termina a instalação ele é comfigurado para hibernar a ms coloco desligar mas é uma jogada de market.
Se quiser o linux também pode hibernar.

1 curtida

Tem algumas dicas

1 curtida

Exatamente, eu tinha um notebook antigo que a Bios mostrava “retornando da hibernação”, isso aconteceu no Windows 10 e antes no 8 (foi quando eles implementaram a tal da “inicialização rápida”) mesmo tendo clicado em “Desligar”.

Enfim, eu posso dizer também que quando migrei para o Arch Linux me surpreendeu demais a velocidade do boot, justamente porque o sistema é enxuto.

2 curtidas

não dá p comparar os dois.

o arch tem boot rápido pq usa o systemd-boot ou efistub, que dispensa gerenciador de boot.

Bem, eu tenho usado o systemd-boot (bootctl), você quem escolhe na instalação, mas, o meu ponto é que como ele carrega apenas os processos básicos de cada interface, isso diminui o uso de memória e, consequentemente, o tempo de boot.

Eu não recomendo instalá-lo caso sua única necessidade for essa, isso porque cada SO atende um público, porém, se você tem conhecimento e paciência para configurar, vale testar pelo menos para tu ter uma comparação.

1 curtida