16.04 Suportando tempos de inicialização lentos no SSD Crucial MX300. O Systemd-analyze blame mostra diferentes serviços levando longos tempos a cada inicialização

Question

Devo observar que este é um sistema de inicialização dupla com o Windows 10.

Aqui está o meu mais recente systemd-analyze

Startup finished in 20.022s (firmware) + 2.835s (loader) + 2.215s (kernel) + 36.136s (userspace) = 1min 1.211s

Aqui está o meu mais recente systemd-analyze blame

         56.166s upower.service
         35.175s lightdm.service
         35.157s plymouth-quit-wait.service
           996ms systemd-rfkill.service
           637ms dev-sdb5.device
           102ms ModemManager.service
            98ms accounts-daemon.service
            94ms networking.service
            93ms systemd-udevd.service
            89ms NetworkManager.service
            76ms grub-common.service
            76ms thermald.service
            75ms apport.service
            68ms systemd-journald.service
            50ms systemd-udev-trigger.service
            46ms keyboard-setup.service
            45ms systemd-logind.service
            45ms avahi-daemon.service
            38ms irqbalance.service
            37ms apparmor.service
            36ms systemd-tmpfiles-clean.service
            32ms console-setup.service
            31ms ondemand.service
            28ms speech-dispatcher.service
            27ms systemd-fsck@dev-disk-by\x2duuid-8655\x2d1473.service
            26ms systemd-modules-load.service
            23ms systemd-tmpfiles-setup-dev.service
            22ms udisks2.service
            22ms plymouth-start.service
            22ms gpu-manager.service
            18ms alsa-restore.service
            15ms pppd-dns.service
            15ms systemd-user-sessions.service
            12ms rsyslog.service
            11ms plymouth-read-write.service
            10ms systemd-update-utmp.service
            10ms polkitd.service
             9ms colord.service
             9ms dev-mqueue.mount
             9ms [email protected]
             9ms bluetooth.service
             8ms systemd-timesyncd.service
             8ms wpa_supplicant.service
             7ms systemd-sysctl.service
             7ms systemd-journal-flush.service
             7ms ufw.service
             6ms sys-kernel-debug.mount
             6ms ureadahead-stop.service
             5ms systemd-tmpfiles-setup.service
             5ms kmod-static-nodes.service
             4ms snapd.autoimport.service
             3ms systemd-random-seed.service
             3ms systemd-update-utmp-runlevel.service
             3ms dev-hugepages.mount
             3ms dev-sdb6.swap
             3ms systemd-remount-fs.service
             2ms resolvconf.service
             2ms dns-clean.service
             2ms boot-efi.mount
             1ms rtkit-daemon.service
             1ms sys-fs-fuse-connections.mount
             1ms setvtrgb.service
             1ms rc-local.service
           351us snapd.socket

Os tempos realmente não somam e sempre há serviços diferentes que levam muito tempo. Uma outra inicialização tem ModemManager.service levando 50 segundos. Outra inicialização teve um processo diferente, levando 1 min 30.

Eu desinstalei e reinstalei várias vezes e não consigo entender. A ajuda é apreciada e cuidado, eu sou um novo usuário.

    

Answer 1

Seu / dev / sdb está recebendo erros de E / S. Isso não é bom para um novo SSD.

Primeiro, revise os dados SMART e faça o teste rápido. Abra o aplicativo Disks , selecione o SSD no painel esquerdo, vá para o ícone "hamburger", selecione SMART Data & Tests . Revise os dados e execute o teste curto. Aviso ... NÃO execute um teste de bloqueio ruim em um SSD.

Em segundo lugar, acesse o site da Crucial no link e faça o download do firmware mais recente datado de 16/5/2017 . O novo firmware lida melhor com os erros que você está recebendo. PRIMEIRO backup de seus dados importantes, então instale o novo firmware.

Continue a monitorar /var/log/syslog para erros de sdb ...

Em terminal ...

grep -i sdb /var/log/syslog*

Se eles continuarem, registre um ticket de garantia com Crucial.

Atualização # 1:

O problema foi finalmente resolvido com o parâmetro do kernel libata.force=noncq .