Cfrgtkky

After booting I ran systemd-analyze blame and here are the results:

     21.596s systemd-journal-flush.service

     18.658s dev-sda8.device

     15.099s dev-loop33.device

     15.034s dev-loop19.device

     15.012s dev-loop34.device

     14.989s dev-loop21.device

     14.877s dev-loop15.device

     14.866s dev-loop26.device

     14.773s dev-loop27.device

     14.684s dev-loop30.device

     14.677s dev-loop32.device

     14.649s dev-loop35.device

     14.590s dev-loop25.device

     14.267s dev-loop23.device

     14.192s dev-loop24.device

     14.156s dev-loop29.device

     14.133s dev-loop16.device

     14.065s dev-loop31.device

     14.059s dev-loop28.device

     13.821s dev-loop20.device

     13.531s dev-loop22.device

     13.495s dev-loop14.device

     13.364s dev-loop18.device

What are these dev-loopxx.device (xx denotes numbers) services and why are they taking so much time? Are they related to the mounting of snaps? Can I reduce the boot time by disabling them? I'm running Ubuntu 18.04 alongside Windows 10.

You can determine the list of all installed snaps with snap list, for relation between mount-point and snap name you can use systemctl status, mount and losetup.

For example on my Ubuntu MATE 18.04 LTS I have the following snaps installed:

$ snap list

Name                 Version           Rev   Tracking  Developer      Notes

core                 16-2.33.1         4917  stable    canonical      core

software-boutique    18.04.0-5b99b84   31    stable/…  flexiondotorg  classic

ubuntu-mate-welcome  17.10.23-e4f4c4c  169   stable/…  flexiondotorg  classic

They create loop-devices as follows:

$ systemd-analyze blame | grep dev-loop

          4.303s dev-loop4.device

          4.267s dev-loop2.device

          4.193s dev-loop0.device

          4.146s dev-loop3.device

           111ms dev-loop5.device

Mount points are as following:

$ mount | grep snapd

/var/lib/snapd/snaps/core_4830.snap on /snap/core/4830 type squashfs (ro,nodev,relatime,x-gdu.hide)

/var/lib/snapd/snaps/ubuntu-mate-welcome_169.snap on /snap/ubuntu-mate-welcome/169 type squashfs (ro,nodev,relatime,x-gdu.hide)

/var/lib/snapd/snaps/software-boutique_31.snap on /snap/software-boutique/31 type squashfs (ro,nodev,relatime,x-gdu.hide)

/var/lib/snapd/snaps/core_4650.snap on /snap/core/4650 type squashfs (ro,nodev,relatime,x-gdu.hide)

/var/lib/snapd/snaps/core_4917.snap on /snap/core/4917 type squashfs (ro,nodev,relatime,x-gdu.hide)

Let's look closer to dev-loop4.device:

$ systemctl status dev-loop4.device

● dev-loop4.device - /dev/loop4

   Follow: unit currently follows state of sys-devices-virtual-block-loop4.device

   Loaded: loaded

   Active: active (plugged) since Tue 2018-07-17 13:05:41 MSK; 4min 44s ago

   Device: /sys/devices/virtual/block/loop4

The folder /sys/devices/virtual/block/loop4 contains very useful file loop/backing_file, we can read its contents:

$ cat /sys/devices/virtual/block/loop4/loop/backing_file 

/var/lib/snapd/snaps/core_4650.snap

So we just determined that /dev/loop4 is created by core snap.

But the easiest way is to use losetup (see man losetup):

$ losetup 

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                         DIO LOG-SEC

/dev/loop4         0      0         1  1 /var/lib/snapd/snaps/core_4650.snap                 0     512

/dev/loop2         0      0         1  1 /var/lib/snapd/snaps/ubuntu-mate-welcome_169.snap   0     512

/dev/loop0         0      0         1  1 /var/lib/snapd/snaps/core_4830.snap                 0     512

/dev/loop5         0      0         1  1 /var/lib/snapd/snaps/core_4917.snap                 0     512

/dev/loop3         0      0         1  1 /var/lib/snapd/snaps/software-boutique_31.snap      0     512

Hope this helps to understand Snaps mount-points better.

Bottom-line: by using Snaps for having up-to-date software, we end up paying for it with higher network traffic, more disk usage and slower boot time. If you do not want to use Snaps at all, then remove them with sudo apt-get purge snapd.