Really slow boot on Ubuntu 16.10 Alienware 17R3

Question

I'm trying to figure out what is going on with my system. It takes too long to boot.

It is a dual boot with Windows on an Alienware 17R3. I tried to do what these posts suggest:

• Really slow boot on 16.04
• Very slow boot with Ubuntu 15.04

But that doesn't seem to be my problem. Although some errors are related to dev-sda4.device.

The output of dmesg is here. And the output of systemd-analyze plot is dumped here.

Also

$ systemd-analyze blame
     17.674s grub-common.service
     17.564s networking.service
     17.519s apport.service
     17.518s irqbalance.service
     17.448s sysstat.service
     16.852s click-system-hooks.service
     13.048s speech-dispatcher.service
      7.556s ModemManager.service
      7.539s dev-sda4.device
      6.824s accounts-daemon.service
      4.761s apparmor.service
      4.706s alsa-restore.service
      4.452s systemd-logind.service
      4.404s iio-sensor-proxy.service
      4.402s gpu-manager.service
      4.227s thermald.service
      4.190s avahi-daemon.service
      4.188s bluetooth.service
      3.926s snapd.firstboot.service
      3.120s NetworkManager.service
      2.151s polkitd.service
      1.922s systemd-tmpfiles-setup.service
      1.636s systemd-fsck@dev-disk-by\x2duuid-E237\x2d4151.service
      1.536s systemd-rfkill.service
      1.511s systemd-udevd.service
      1.470s plymouth-start.service
      1.406s wpa_supplicant.service
      1.323s keyboard-setup.service
      1.173s systemd-tmpfiles-setup-dev.service
      1.141s systemd-backlight@backlight:intel_backlight.service
       956ms user@1000.service
       950ms packagekit.service
       940ms systemd-modules-load.service
       851ms rsyslog.service
       838ms console-setup.service
       603ms upower.service
       564ms dev-sda5.swap
       558ms sys-kernel-debug.mount
       557ms dev-mqueue.mount
       557ms dev-hugepages.mount
       522ms udisks2.service
       314ms lightdm.service
       309ms systemd-timesyncd.service
       293ms plymouth-quit-wait.service
       257ms systemd-journald.service
       235ms systemd-resolved.service
       232ms boot-efi.mount
       232ms dns-clean.service
       202ms pppd-dns.service
       192ms ufw.service
       181ms systemd-update-utmp.service
       177ms snapd.socket
       171ms systemd-udev-trigger.service
       128ms colord.service
       112ms systemd-sysctl.service
       103ms kmod-static-nodes.service
       101ms systemd-journal-flush.service
       100ms systemd-random-seed.service
        78ms systemd-remount-fs.service
        57ms systemd-tmpfiles-clean.service
        40ms nvidia-persistenced.service
        34ms setvtrgb.service
        21ms snapd.boot-ok.service
        12ms systemd-user-sessions.service
        12ms openvpn.service
        11ms rc-local.service
        11ms systemd-update-utmp-runlevel.service
        11ms plymouth-read-write.service
        10ms ureadahead-stop.service
         3ms rtkit-daemon.service
         2ms cgroupfs-mount.service
         1ms resolvconf.service
         1ms sys-fs-fuse-connections.mount

Any hints on how to solve this are appreciated.

Answer 1

This is a problem with your hard drive, I had experienced the same problem on alienware area 51 and have replaced hard drive with old data image from old hard drive restored onto it and it worked absolutely fast, much faster, see if that solves your problem, if not, update your bios that REALLY helps.

Answer 2

In systemd you can disable services with sudo systemctl disable [service].

For grub-common.service it appears to be safe to disable, see here.

With networking.service, it often hangs when the loopback-device is not properly defined, see here

apport.service starts the automatic-crash report daemon, so if you never filed bugs, or want to search for errors by your own, you might disable it as well - more about Apport here

The next two culprits irqbalance.service and sysstat.service- I would not tamper with.

As long as you have not installed any snap packages or the predecessor click-packages, I see no reason to why not to disable click-system-hooks.service and snapd.firstboot.service.

If your eye-sight is good to normal, the speech-dispatcher.service can go as well.

So we have won about 1min of boot time, if you like to experiment along, do so. Oh yeah services get reenabled by sudo systemctl enable [service] - more systemctl coptions can be found in this question.