Ubuntu 18.04 boot extremely slow

[John Bester]

I have upgraded Ubuntu 16.04 (amd64) using Gnome as desktop to Ubuntu 18.04. Ubuntu 16.04 took just over 20 seconds from the time a selection on the Grub boot menu was made until the login screen was displayed. On Ubuntu 18.04 it takes about 20 seconds (from Grub menu) to display the boot splash screen and in total it takes about 2min 30sec until the login menu (gdm) is displayed.

Expected behaviour:
I would expect a new LTS release to have a similar boot time than the previous release. At this time I am experiencing boot times slower that those I had a few years ago from a traditional hard drive (which used to be just under 2min)

Additional information:
I have recently built two Ubuntu servers (17.10 in expectation of upgrading to 18.04 upon release). I found that the boot process went fairly smooth right until the end where it seems to wait for about a minute for what seems to be a network connection. After that wait period the text login prompt is displayed. So I am guessing that there might be a service start timeout which blocks the process.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic

$ uname -a
Linux popeye 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tonio (glazdzero)]

This happened to me after upgrading 17.10 to 18.04.
I decided to do a fresh install of 18.04 and problem persists.

[Tonio (glazdzero)]

Ubuntu 18.04 also weirdly freezes for about 1 minute when opening the system configuration menu. That is something that didn't happen in my previous 17.10 installation and somehow prevents me from setting up a monitor in my laptop. I wonder if this issue is related, since these are the only 2 problems I've been experiencing since 18.04.

[Tonio (glazdzero)]

So I went through some logs and besides having a LOT of plymouth messages in the boot log cycling from "A start job is running for Tell Plymouth To Write Out Runtime Data" to "A start job is running for Show Plymouth Boot Screen", I noticed the kernel log throwing several KMS timeout errors as well.

So I googled a bit and found out this thread: https://askubuntu.com/questions/893817/boot-very-slow-because-of-drm-kms-helper-errors

It patched the bug for me. No longer slow boot/shutdown and strange freezings in the Settings menus.

[John Bester (john-bester)]

Although I did not get the same entry in dmesg as Tonio, it did point me towards dmesg. So I have attached my dmesg ouput. I have listed the parts where significant time is somehow lost (please note that I am not an expert and therefore I am not able to tell where exactly the gdm login screen appeared).

#1
[ 2.780216] clocksource: Switched to clocksource tsc
[ 34.422902] random: crng init done

#2
[ 40.242284] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null)
[ 128.816712] audit: type=1400 audit(1525590690.456:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4486/usr/lib
/snapd/snap-confine" pid=1126 comm="apparmor_parser"

#3
[ 135.805543] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[ 166.755990] ata4: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozen

#4
[ 171.739128] rfkill: input handler disabled
[ 193.135040] FS-Cache: Loaded

#5 & 6
[ 193.148640] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 261.690048] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 467.025578] kauditd_printk_skb: 48 callbacks suppressed

[Tito José Ferreira Figueiredo (titojff)]

just found out that after a fresh install theres no slowdown, is after all the updates.

Tomorrow I will make snapshots and parcial updates until I found which of the updates is causing this..

[Tito José Ferreira Figueiredo (titojff)]

This kernel update causes the slowdown, from the 4.15.0-20 that is installed to 4.15.0-24.26 that comes in the initial Update

[Angelo Giacomini Ribas (angelo-ribas-adv)]

Same problem here after upgrading to kernel 4.5.0-24.26:

user@machine:~$ sudo systemd-analyze blame
    7min 50.750s plymouth-quit-wait.service
    6min 17.955s snapd.seeded.service
         15.700s snapd.service
          6.253s NetworkManager-wait-online.service
          1.502s dev-mapper-ubuntu\x2d\x2dvg\x2droot.device
          1.231s dev-loop0.device
          1.223s dev-loop1.device
          1.203s dev-loop2.device
          1.182s dev-loop3.device
           737ms fwupd.service
           265ms networkd-dispatcher.service
           253ms NetworkManager.service
           244ms plymouth-start.service
           230ms apparmor.service
           223ms udisks2.service
           199ms ModemManager.service
           190ms keyboard-setup.service
           182ms systemd-logind.service
           177ms systemd-journal-flush.service
           173ms accounts-daemon.service
           168ms systemd-udev-trigger.service
           149ms systemd-rfkill.service
           132ms speech-dispatcher.service
           127ms apport.service
           125ms systemd-timesyncd.service
           123ms avahi-daemon.service
           122ms systemd-resolved.service
           112ms bluetooth.service
           109ms packagekit.service
           109ms systemd-journald.service
           106ms grub-common.service
            99ms lvm2-pvscan@8:1.service
            95ms lvm2-monitor.service
            93ms wpa_supplicant.service
            89ms upower.service
            85ms thermald.service
            81ms networking.service
            81ms pppd-dns.service
lines 1-38

However, interestingly, if I move mouse while booting, the output differs greatly:

user@machine:~$ sudo systemd-analyze blame
          6.294s NetworkManager-wait-online.service
          4.453s plymouth-quit-wait.service
          1.474s dev-mapper-ubuntu\x2d\x2dvg\x2droot.device
          1.257s dev-loop0.device
          1.246s dev-loop1.device
          1.227s dev-loop2.device
          1.204s dev-loop3.device
          1.060s snapd.service
           749ms fwupd.service
           410ms apparmor.service
           333ms networkd-dispatcher.service
           327ms udisks2.service
           255ms NetworkManager.service
           247ms plymouth-start.service
           216ms ModemManager.service
           199ms systemd-rfkill.service
           195ms accounts-daemon.service
           190ms systemd-journal-flush.service
           168ms systemd-logind.service
           157ms systemd-timesyncd.service
           154ms keyboard-setup.service
           150ms systemd-resolved.service
           137ms systemd-udev-trigger.service
           122ms thermald.service
           110ms grub-common.service
           109ms avahi-daemon.service
           106ms wpa_supplicant.service
           103ms systemd-journald.service
           102ms apport.service
           102ms bluetooth.service
            97ms packagekit.service
            94ms networking.service
            93ms upower.service
            90ms lvm2-pvscan@8:1.service
            90ms lvm2-monitor.service
            83ms gpu-manager.service

[Daniel van Vugt (vanvugt)]

It sounds like one cause of the problem might have been found in bug 1779476.

[Dmitry Kudriavtsev (dkudriavtsev)]

Seems like the bug is happening because not enough entropy is being generated (clues: snapd.seeded.service and mouse movement decreasing boot time)

[Daniel van Vugt (vanvugt)]

Ignore my previous comment. See bug 1779827 instead.

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1767782, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

[mak berlin (8-mak)]

Ive the same problem after a fresh instalation on lenovo x240 with kernel 4.15.0-43-generic
graphical.target @33.937s
└─multi-user.target @33.937s
  └─kerneloops.service @33.921s +14ms
    └─network-online.target @33.916s
      └─NetworkManager-wait-online.service @23.532s +10.383s
        └─NetworkManager.service @19.373s +4.156s
          └─dbus.service @18.769s
            └─basic.target @18.694s
              └─sockets.target @18.693s
                └─snapd.socket @18.614s +67ms
                  └─sysinit.target @18.530s
                    └─swap.target @18.528s
                      └─dev-mapper-ubuntu\x2d\x2dvg\x2dswap_1.swap @18.481s +44ms
                        └─dev-mapper-ubuntu\x2d\x2dvg\x2dswap_1.device @18.480s

[Mark (slowboot)]

Easy Solution=
From the Old Version, use =

sudo apt-get update
sudo do-release-upgrade

Boot speed will be the same as the old version speed
do not install with CD or USB

[Miroslav Zaťko (mirec-z)]

seems like the same problem is still there with Ubuntu 19.10

[Daniel van Vugt (vanvugt)]

This bug was deemed a duplicate of bug 1685794. So if that's relevant to you then please comment in bug 1685794 instead. If it's not relevant to you then please open a new bug by running:

  ubuntu-bug plymouth