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.
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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments