19.10 Beta - Atrocious boot times

The 19.10 thread is going to become unreadable if we don't break a few of these out...

boot-to-desktop time is terrible - very nearly a full minute. To put that in perspective, this VM, on 16.04, reaches the desktop in 3.7s. That's a hell of a regression.

Doubtless just yet another systemd service blocking things until it's downloaded half the Internet, and probably not something UM will be allowed to fix, but it's still not a good impression for a new release, especially when upgrading to something that's supposed to be better.

(It seems to be multiple things, but systemd-resolved alone is adding close to 20s to it).

And, jep, it was. Boot time is still terrible, at 41s, but that's still a huge improvement.


HOWTO

see https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu

$ sudo systemctl disable systemd-resolved
$ sudo systemctl stop systemd-resolved

Then put the following line in the [main] section of your /etc/NetworkManager/NetworkManager.conf:
dns=default

Delete the symlink /etc/resolv.conf
$ rm /etc/resolv.conf

Restart NetworkManager
$ sudo systemctl restart NetworkManager


The VAST majority of the remaining 41s is spent at a TTY login. IOW, the system is actually up and running, and there's just yet another (or several) bad or badly-specified services blocking lightdm from actually running.

For those not familiar with systemd, this part of it is basically a straight copy of the Windows services system. You build strings of dependencies (ordered lists of which things have to start before which other things). As a trivial example, you can't set your clock from the network (NTP) until the network is up.

It's an excellent concept (regardless of the quality of the implementation) but can be royally screwed up by someone Doing Something Stupid with those strings, like "You can't log in until the clock's set" - which means that if your Internet connection is down, you can't get to a desktop at all.


okay - IDK what the hell it's doing, but it's thrashing the disk like crazy. Since I've got ~10GB of RAM free to use as cache and it's warm, it has to be writes. blame and critical-chain are claiming that "nothing" is stopping the boot, so it's probably just bad behavior from something stupid in systemd just grinding IO rather than a dependency, but it'll have to wait until tomorrow.

resolveD was 20s - the other big offender turned out to be the VirtualBox guest modules, which were repeatedly being rebuilt at boot because the build was failing. Now it's all behaving properly again.

I did kill off half a dozen other garbage services (pppd, multiple network-searching services, etc) as well, but those shouldn't have been affecting the boot time in any meaningful way.

For anyone having problems with using a VB guest to test the beta, make sure the client module is:
$ /usr/bin/VBoxClient -V
6.0.12_Ubuntur132055
which you can get from the MATE repos (virtualbox-guest-source, virtualbox-guest-utils, virtualbox-guest-x11). Not that the guest modules are NOT automatically built the way they should be: see /usr/share/doc/virtualbox-guest-source/README.Debian on how to do that by hand.