Ubuntu: 16.04 Suffering slow boot times on Crucial MX300 SSD. Systemd-analyze blame shows different services taking long times each boot



Question:

I should note that this is a dual boot system with Windows 10.

Here's my latest systemd-analyze

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

Here's my latest 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 user@1000.service               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  

The times don't really add up and there's always different services taking a long time. One other boot has ModemManager.service taking 50 seconds. Another boot had a different process taking 1 min 30.

I have uninstalled and reinstalled multiple times and I can't figure it out. Help is appreciated and beware I am a new user.


Solution:1

Your /dev/sdb is getting I/O errors. That's not good for a new SSD.

First, review the SMART data and run the short test. Open the Disks app, select the SSD in the left pane, go to the "hamburger" icon, select SMART Data & Tests. Review the data, and run the short test. Warning... do NOT run a badblock test on a SSD.

Second, go to the Crucial web site at http://www.crucial.com/usa/en/support-ssd-firmware, and download the latest firmware dated 5/16/2017. The new firmware better handles exactly the errors that you're getting. FIRST backup your important data, THEN install the new firmware.

Continue to monitor /var/log/syslog for sdb errors...

In terminal...

grep -i sdb /var/log/syslog*  

If they continue, log a warranty ticket with Crucial.

Update #1:

Problem was ultimately solved with kernel parameter libata.force=noncq.


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »