29

I'be been running 18.04 since a clean SSD install on the day of it's official release, without issues.
Power on to login was seconds (max 10)

Then, I did a regular upgrade this morning:

$ sudo apt update && sudo apt dist-upgrade

The packages installed/upgraded were:

Install: linux-headers-4.15.0-24:amd64 (4.15.0-24.26, automatic), linux-headers-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-extra-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-image-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic)
Upgrade: gnome-control-center-data:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-headers-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-image-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), linux-signed-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center-faces:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-generic:amd64 (4.15.0.23.25, 4.15.0.24.26)

I rebooted once the upgrade had completed, and noted a 2-3 minute delay on the Ubuntu loading/splash screen (prior to login) (without any progress/activity indicated on the dots).

I powered off and tried to boot again, but am getting this delay consistently now. Also close down is much slower too.

Update #1 (2018-07-03):
Analysis on systemd:

$ sudo systemd-analyze blame
3min 53.073s plymouth-quit-wait.service
    2min 20.699s snapd.seeded.service
         49.949s snapd.service
          6.186s NetworkManager-wait-online.service
          1.148s dev-sda2.device
          1.098s plymouth-start.service

Showing that plymouth-quit-wait.service (which I now believe is related to the Ubuntu loading/splash screen) and snapd.seeded.service were by far the longest running services to initiate. So I compared the times before the dist-upgrade and after:

$ journalctl -u plymouth-quit-wait.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:38:05 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:15:46 user-laptop systemd[1]: Started Hold until boot process finishes up.
-- Reboot --
Jul 03 04:21:17 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:24:52 user-laptop systemd[1]: Started Hold until boot process finishes up.

Before the upgrade plymouth-quit-wait.service took 3 seconds. After the upgrade it took 3 minutes 35 seconds

$ journalctl -u snapd.seeded.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:42:14 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:15:43 user-laptop systemd[1]: Started Wait until snapd is fully seeded.
-- Reboot --
Jul 03 04:22:47 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:24:49 user-laptop systemd[1]: Started Wait until snapd is fully seeded.

Before the upgrade snapd.seeded.service took 0 seconds. After the upgrade it took 2 minutes 2 seconds.

Update #2 (2018-07-06):
This morning's boot saw the return of the delay.
So I guess we're still waiting for the kernel/plymouth/snapd update.

Update #3 (2018-07-12):
The problem seems to be resolved, but I didn't see any update to snap or plymouth, and I'm still running 4.15.0-24 kernel. So I'm not sure which package update fixed the problem, or if it just resolved itself somehow. Reading the bug updates on launchpad it's unclear to me what was done (or is being done) to what package/s. If anyone can clarify that would be very useful.

Broadsworde
  • 4,132
  • 4
  • 28
  • 45
  • Looks to me like snapd was seeding (refreshing the snap database) for 2:20. A rare event, nothing broken. If it does that every time, file a bug against snapd. – user535733 Jul 03 '18 at 13:09
  • Thanks for that. So far the snapd seeding is consistently running at over 2 mins each boot after the dist-upgrade, having taken zero seconds before it. – Broadsworde Jul 03 '18 at 13:36
  • 1
    I'm having the same issue after a new installation of Ubuntu 18.04:

    3min 57.515s plymouth-quit-wait.service

    2min 24.588s snapd.seeded.service

     – Alessandro Gaballo Jul 03 '18 at 14:05
  • 1
    I had this same issue today after upgrading my kernel to 4.15.0-24-generic. – user605331 Jul 03 '18 at 14:33
  • 1
    Consider starting a thread on https://forum.snapcraft.io . That's where the snap developers hang out. Be sure to start a thread ONLY if you're willing to help them troubleshoot and test. Everybody should subscribe to the same thread, and avoid useless 'me too' comments - keep the noise down so the developers don't get discouraged and turn off. – user535733 Jul 03 '18 at 14:40
  • 2
    I logged a bug at: https://bugs.launchpad.net/snapd/+bug/1779872 I'm certainly willing to help troubleshoot – Broadsworde Jul 03 '18 at 15:10
  • This bug affected my Ubuntu 18.04 LTS system the first time I booted after upgrading the kernel. But the second and third times I booted, it no longer affected my Ubuntu. – sudodus Jul 04 '18 at 09:13
  • Could you please open a new question if you have a new or follow-up question? If you tack hardly related questions onto existing questions you broaden their scope which makes them harder to answer. On top of that it likely invalidates existing answers. I took the liberty to revert the edit that adds the follow-up question. Thanks. I took the liberty to revert those drastic changes. – David Foerster Jul 07 '18 at 14:48
  • This is NOT a problem related to a development version of Ubuntu. It relates to the released version 18.04 and was triggered by a regular and clearly broken software update sent to all users. – msc Jul 12 '18 at 06:20

4 Answers4

16

This is a kernel related regression, the launchpad bug is: https://bugs.launchpad.net/ubuntu/+bug/1779827

As a workaround, press keys and/or move the mouse at boot.

In a nutshell services that use /dev/urandom or getrandom() now block until enough entropy is available. In the past much less entropy was required for /dev/urandom.

The latest status from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 is that:

The meta-packages have been rolled back and the fix is in progress of being applied and uploaded.

The snapd team also looked into this and worked with bson upstream to ensure no /dev/unrandom is needed to startup (https://github.com/snapcore/snapd/pull/5464)

So this problem should be fixed via either a kernel or a snapd update soon.

muru
  • 197,895
  • 55
  • 485
  • 740
Michael Vogt
  • 456
  • 1
    I just tried the "shift" boot and that seemed to reflect the boot to login times I had been seeing before the update... so what is broken here? BTW, "shift" at boot didn't give me a grub menu, but it did give me a login much quicker. – Broadsworde Jul 04 '18 at 08:06
  • Michael, could you [edit] this answer and incorporate the information from your other answer into this one and then delete the other one? We like one question, one answer here... Thank you! ;-) – Fabby Jul 04 '18 at 17:08
  • please contact a mod to have your accounts merged – Zanna Jul 04 '18 at 17:18
  • @Broadsworde, Spamming (repeated hitting) the shift key or the Esc key in Ubuntu 18.04 LTS brings up the grub menu for me. (It is not enough to just keep the key down; I guess it can differ between computers.) – sudodus Jul 05 '18 at 07:37
13

You can move mouse or increase entropy in system.

sudo apt install haveged

haveged website

Works for default kernel and from ukuu. This allows the system to boot up correctly on kernel 4.17.4.

muru
  • 197,895
  • 55
  • 485
  • 740
Radoslaw Brzozowski
  • 131
  • Interesting solution. I don't have the problem yet because I recently switched to 4.4.0-130 for Virtualbox experimenting, but I installed haveged to future-proof my machine. – WinEunuuchs2Unix Jul 10 '18 at 10:16
6

I've seen this manifest on two desktops I manage. Running the following command to install rng-tools solves the issue for me:

sudo apt install rng-tools

From Arch wiki: The rng-tools is a set of utilities related to random number generation in kernel. This is mainly useful to increase the quantity of entropy in kernel to make /dev/random faster.

psiphi75
  • 946
  • 1
  • 13
  • 25
5

i've the same issue with 4.15.0-24-generic #26-Ubuntu SMP

user@nb:~$ systemd-analyze blame |head
         4min 2s plymouth-quit-wait.service
          1.440s systemd-udev-settle.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

For a temporary workaround, you just need to move your mouse / touchpad while booting, resulting in a "normal" boot time; in my case:

user@nb:~$ systemd-analyze blame |head
          1.440s systemd-udev-settle.service
           882ms plymouth-quit-wait.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

Fix Source: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Francio
  • 51
  • 2