Você pode tentar descobrir o que leva mais tempo com o systemd
systemd-analyze blame
Você pode tentar descobrir o que leva mais tempo com o systemd
systemd-analyze blame
Editar o UUID do / etc / fstab do espaço de troca (para corresponder à saída de sudo blkid ) funcionou como um encanto!
No meu SSD, a inicialização passou de 2 minutos para menos de 10 segundos.
O problema é que eu fiz uma atualização normal de 14.04 para 16.04, sem mexer nas partições, quando esse problema começou. Claramente, há alguns problemas com o procedimento de atualização.
Eu encontrei um problema semelhante de maior tempo de inicialização após a atualização.
Qual foi o problema? Eu tinha deletado meu espaço de troca, então meu arquivo / etc / fstab e o novo sistema de arquivos tinham conflitos. O carregador de boot aguardou quase 1m 30s para encontrá-lo.
Como resolvi o problema Corre sudo blkid
Abra seu arquivo / etc / fstab e compare a correspondência do uuid com as partições que você possui. Se houver incompatibilidade mudar isso e reinicie.
É uma solução alternativa, mas isso reduziu significativamente o tempo de inicialização (de 1 min 24s para 16s).
sudo vim /etc/systemd/system.conf
Descomente estes dois parâmetros e defina o tempo limite desejado:
DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s
Conforme discutido aqui , esses parâmetros configuram os tempos limite padrão para iniciar e parar de unidades, bem como o tempo padrão para dormir entre reinicializações automáticas de unidades, conforme configurado por unidade em TimeoutStartSec= , TimeoutStopSec= e RestartSec= (para serviços, consulte systemd.service (5) para obter detalhes sobre o configurações de unidade).
Para unidades sem serviço, DefaultTimeoutStartSec= define o padrão TimeoutSec= value . DefaultTimeoutStartSec= e DefaultTimeoutStopSec= padrão para 90s. DefaultRestartSec= é padronizado para 100 ms.
Editar - Mais em detalhe:
Analisei a sequência de inicialização com systemd-analyze plot > sequence.svg que mostrava que os serviços não estavam sendo iniciados no sistema operacional atualizado recentemente. Havia três - um era um daemon sendmail configurado incorretamente e então powerd.service & amp; NetworkManager-wait-online.service . Como não é uma boa idéia desabilitar o serviço NetworkManager por completo, apenas deixo o tempo limite após 10 segundos e aplico essa regra globalmente.
Isso pode estar relacionado a problemas no sistema de arquivos. Você pode querer verificar este link para ver se reparar seu sistema de arquivos melhora o tempo de inicialização: link
Eu tive um problema semelhante que acabei de resolver: eu corro o Ubuntu 16.04 em um SSD. Eu uso um pen drive como partição swap. A unidade tinha sido movida ligeiramente e demorou mais de 3 minutos para arrancar. Eu coloquei de volta corretamente e agora está tudo bem. Caso você tenha tentado o smartctl ou o fsck e o seu sistema de arquivos é o.k, tente remover flash drives (ou outros periféricos) e veja como funciona. Boa sorte!
Com base na sua saída pastebin, algumas coisas surgem em mim:
EXT4-fs (sda5): re-mounted
Você pode querer fsck este volume e dar uma olhada em < um href="https://sobrelinux.info/questions/1264/how-can-i-check-the-smart-status-of-a-ssd-or-hdd-on-current-versions-of-ubuntu-1" > Dados Inteligentes para essa unidade.
e
[ 31.022220] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 45.720952] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 45.761548] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Você pode tentar desabilitar o IPV6 em suas conexões de rede se a sua conexão não apoiá-lo.
Seguindo a dica do user536489:
systemd-analyze blame
Verifique se há um serviço que demore para começar e defina um tempo limite menor:
sudo vim /lib/systemd/system/networking.service
Altere TimeoutStartSec para algo como 10s . A página man man
Obtém um valor sem unidade em segundos ou um valor de intervalo de tempo, como "5min 20s". Passe "infinito" para desabilitar a lógica de timeout.