Snapd gets stuck when starting Ubuntu.

[Nur Hussein]

When Ubuntu starts up, snapd fails to start and continuously tries to restart over and over, until it finally relents and works.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: snapd 2.32.5+18.04
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 4 05:47:22 2018
InstallationDate: Installed on 2018-07-03 (0 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

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

[Seth Arnold (seth-arnold)]

This may be a duplicate of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961

[Mark Crompton (cromptonm)]

I believe this may be a different issue to bug 1779961. That bug is (quote) "Boot stops at "Starting Initial cloud-init job (metadata service crawler)..."

However in my case boot pauses and alternately displays "Failed to start snappy daemon, see systemctl status snapd.service for details" and "Starting wait until snapd is fully seeded".

This repeats for about 15 minutes, and then the system continues booting normally, and once booted everything appears to work as normal.

[John Lenton (chipaca)]

Could you add the output of «journalctl -u snapd» to this bug?

[Andy Whitcroft (apw)]

Also could you confirm the version of snapd in play. Finally, could you try installing the current snapd from -proposed to see if the fix for the same issue as bug 1779961 (which is a general randomness issue) also fixes your scenario.

[Mark Crompton (cromptonm)]

Will post data as requested later this week. Bug affects my home PC but I'm away from home for a few days. Thanks.

[Edward (arkticpanda)]

I'm also affected by this. Included journalctl -u snapd output. Have experienced boot times of up to 50min from hanging on the snapd service.

[Edward (arkticpanda)]

Workaround to entirely remove snapd service (assuming you're not using it for any programs):

sudo apt purge snapd ubuntu-core-launcher squashfs-tools

[Gustavo Niemeyer (niemeyer)]

The problem here is lack of entropy in the kernel. A CVE was reported in the kernel related to low entropy, and the modification prevented the data from going out. Unfortunately that means any programs at early boot that attempted to obtain a few bytes of random data would get stuck, potentially for several minutes. That's of course unreasonable, so the patch in the kernel has since been reverted.

In the snapd end we've also modified the particular logic that used the random data to use a different strategy, since the entropy was not important for the particular use we had for the data at play.

So this should be fixed on both ends by now: the kernel was reverted, and snapd won't get blocked if that happens elsewhere. So an update should guarantee that you won't observe this anymore.

[Nathaniel Johnson (nate.j586)]

When attempting to boot 18.04 on a virtualbox vm, this problem occurs if I have "solid state drive" selected in the options for the virtual hard disk. System will not boot due to start process running for snappy daemon. If I uncheck "solid state drive", the system boots normally. Not sure if this is relevant.

[Mark Crompton (cromptonm)]

@ Nathaniel
I'm also running a SSD on my real (not virtual) machine.

@ Gustavo
Thanks for the info and fix.
I can confirm that bug exists with snapd V2.33.1 and kernel V4.15.0-24
But snapd V2.33.1 and kernel V4.15.0-23 works, no problem.

I have not yet tried later versions of kernel.

[Jiří Doubravský (doubr)]

"sudo apt get haveged" is workaround solution

[Mark Crompton (cromptonm)]

I can confirm bug is fixed with following versions:
snapd 2.33.1+18.04ubuntu2
kernel 4.15.0-29-generic

Thanks :-)

[Woonjas (woonjas)]

I'm on snapd 2.34.2 with 4.15.0-33 kernel and I'm still running into this. It takes me on average 3 tries to get my system to boot (I don't have patience to wait to see if snapd decides to play ball or not)

[Gustavo Niemeyer (niemeyer)]

Woonjas, if you're having an issue, it's probably not this one as the problem was found and fixed.

Can you please open a separate bug, and include the same details requested above for your machine, so we can investigate in more detail?

Thank you.

[Woonjas (woonjas)]

You might be right - installing haveged definitely didn't make any difference. Pressing shift seemed to work last boot (could've gotten lucky too of course).
I'll see if I can find time to open a new bug

[Ivo (summerborn81)]

Seems the root ccause is lack of /dev/sda or /dev/sdb. I am trying to install ubuntu server on machine with hardware raid, no /dev/sda or dev/sdb. Instlaler complaisn aand then enters the loop.
As soon as I remove the hard disks from raid, it works, so workaround- make sure you have /dev/sda or /dev/sdb..usb stick should do it. :)

[Chris Hutzler (chutzler)]

I'm seeing this same thing when trying to install the latest 18.04.2LTS during the ISO's boot process for installation if it helps anyone

[spalpeen (jeremy-spagnet)]

I see the same issue as Chris Hutzler(post above) while installing ubntu 18.04.2LTS on a machine with SSD only, and don't think any of the workarounds (e.g. apt install something) will serve when trying to install ubuntu in the first place - how should I proceeed?

[Soum (soummous)]

Context : when I run the new VM Ubuntu via virtualbox with ubuntu-18.04.4-desktop-amd64.iso under W10.
Error : the find below the log at the starting ubuntu : [Failed to start wait until snpad is fully seeded.]
It's stuck and I have no prompt for more details (systemctl command).
Could you know why it has failed at this step? Thank's