Aug 22
Slow boot after upgrade to Ubuntu 16.04
On one machine, a laptop with 4GB RAM but a slow HDD, I've come to experience very slowed down bootup times in comparison to 14.04 LTS after upgrade to Ubuntu 16.04 LTS. (We'll ignore the less-snappy UI experience for now, like Nautilus opening or SMPlayer creating and drawing the windows when I click a video, etc.)
So, to say it upfront: I've not yet (fully) solved the issue, so this post is a Work-in-Progress, and may remain so indefinitely (see what I found in section "And?" below). Maybe it's just the hardware being too dated for Ubuntu 16.04 (and I thought this hardware / OS update dance was over with leaving Windows behind...)
I've seen this issue pop up all over the place. Here, here, here, here, here and here. And while it's probable that all these vague issues are not related to the same problem(s), these users here reported a very similar looking slow boot - with apt-daily.service taking very long.
Investigating slow boot times
Linux offers some tools to find out which stages or processes of the boot take long or are causing the slow boot. This post here analyses the boot process very extensively and takes IO etc into account as well. It uses bootchart, but let's see what else we can use to analyze what Ubuntu is doing on startup without installing anything.
dmesg
dmesg is used to dumpt the current system log to STDOUT. If you use it right after boot, for example with dmesg > boot.txt it will tell you what took so long. The numbers in square brackets leading every line are the timestamp since startup, so when you see a gap between two lines, with seconds having elapsed, then you've found something that took longer.
systemd-analyze blame
systemd-analyze is available on Ubtuntu 16.04 but not on 14.04, as the more recent Ubuntu has switched to systemd, as I recall but are too lazy to fully learn and explain now. Anyway, issuing $ systemd-analyze blame will output a table of things happening during bootup sorted by how long they took. It can also print out a nice looking HTML summary with $ systemd-analyze plot > analysis.html
What I did
My feeling now is that over the course of some upgrades the bootup situation has improved slightly. Still apt-daily.service seems to take ages. Something called uml-utilities.service is also taking its bill. And multiple NetworkManager entries, which could be related to this "bug" where a laptop (I'm also discussing a laptop here) is on WLAN and network is trying DHCP discovery on ETH0... Untested - as I don't know right now how to stop that generally on boot, just to try.
Apart from that, this post here has some suggestions about little things you can do to speed things up, like removing ModemManger etc. I actually did $ sudo systemctl disable ModemManager.
Then I decided this apt-daily thing is causing the problem mainly. And apt is for software aupdates, right? So I scoured the web and found this post which explains how to turn updates off. No problem since I do check and upgrade updates manually quite often anyways, at least on this machine which is seldomly connected to WLAN. As suggested I edited /etc/apt/apt.conf.d/10periodic and set APT::Periodic::Update-Package-Lists "0"; to zero. This seems to have flipped the switch on the UI in Adminstration > Software > Updates as well.
And?
Well, much better! I think what is taking time now is the slow HDD, so it's mainly IO now, well.. And looking into blame, after this uml-utilities.services is the top time consumer. And I think it is an essential service. Dunno. From power on to login-screen it takes 60 seconds. And another 55 seconds from login-screen until Unity's "dash" flashes and background image art comes up. But I'm too lazy to see if Unity can be sped-up. Let's call it a day. Poweroff / shutdown takes 2 seconds, though 😉
One more note:
Naive in hindsight, I thought to switch to Lubuntu (which is possible by simply in stalling a few packages) to speed things up. And while the window / UI manager components were a little bit snappier in comparison to Unity, the startup process until login was the same (slow one). Lesson learned. Of course! Arg... Anyway,