boot hangs on vmblock fuse mount

Bug #1448134 reported by Maga Laan on 2015-04-24
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

After upgrading to Ubuntu 15.04 I experience a mayor boot delay of one and half minutes. It does not happen when I boot with upstart in anvanced menu.

"systemd-analyze critical-chain" gives me this:

graphical.target @1min 37.987s
└─multi-user.target @1min 37.987s
  └─kerneloops.service @1min 37.873s +15ms
    └─network-online.target @1min 37.873s
      └─network.target @1min 30.654s
        └─NetworkManager.service @1min 30.450s +202ms
          └─basic.target @1min 30.443s
            └─sockets.target @1min 30.443s
              └─acpid.socket @1min 30.443s
                └─sysinit.target @1min 30.441s
                  └─networking.service @1.547s +363ms
                    └─apparmor.service @1.436s +108ms
                      └─local-fs.target @1.435s
                        └─run-vmblock\x2dfuse.mount @1min 37.977s

Martin Pitt (pitti) wrote :

Can you please give me the output of

   sudo systemctl status -l "run-vmblock\x2dfuse.mount"

Run "sudo journalctl -b > /tmp/journal.txt", and attach your /etc/fstab and /tmp/journal.txt ? Thanks!

Changed in systemd (Ubuntu):
status: New → Incomplete
summary: - Ubuntu 15.04 boot delay
+ boot hangs on vmblock fuse mount
Jef Spaleta (jspaleta) wrote :

Morning,
based on my experience using systemd elsewhere...
Gut tells me this is a network share using fuse defined in fstab which is trying to be mounted before networking is up.

quick fix is to use fstab mount options:
noauto: to tell systemd not to make this mount point a hard dep for the early mounting effort

optionally you can also add
x-systemd.automount: to tell systemd to treat it as a lazy mount

I use this pairing myself now.

Full control of network mounts inside the scope of systemd semantics can be done using dedicated units files like in this cifs example:
http://wiki.openelec.tv/index.php/Mounting_network_shares#Systemd_CIFS_sample_mount

which makes sure the mount unit is ordered after the network-online unit to make sure network is in fact up.

Maga Laan (magalaan) wrote :

~$ sudo systemctl status -l "run-vmblock\x2dfuse.mount"

● run-vmblock\x2dfuse.mount - /run/vmblock-fuse
   Loaded: loaded (/proc/self/mountinfo)
   Active: active (mounted) since za 2015-04-25 00:42:55 CEST; 1h 56min left
    Where: /run/vmblock-fuse
     What: vmware-vmblock

Maga Laan (magalaan) wrote :
Maga Laan (magalaan) wrote :

@Jef Spaleta
I suspect it has to do with mounting a data partition. Mounting three NTSF data partitions on my harddisk (DOCS, DATA, TADA) never gave any problems, but when I added a EXT4 partition on my boot SDD (WORK), it gave me warnings during boot up, though it booted up fine. Seems like systemd is timing out on it.

Where do I put the commands you suggested?

This is the content of /etc/fstab

UUID=6043010a-9ef2-4bfc-be63-edf244c46362 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda2 during installation
UUID=ec53629f-3dea-4baf-b0b3-9065267acb2c none swap sw 0 0
LABEL=DATA /media/user/DATA auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA,x-gvfs-icon=DATA,x-gvfs-symbolic-icon=DATA 0 0
LABEL=DOCS /media/user/DOCS auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DOCS,x-gvfs-icon=DOCS,x-gvfs-symbolic-icon=DOCS 0 0
LABEL=TADA /media/user/TADA auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=TADA,x-gvfs-icon=TADA,x-gvfs-symbolic-icon=TADA 0 0
LABEL=WORK /media/user/WORK auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=WORK,x-gvfs-icon=WORK,x-gvfs-symbolic-icon=WORK 0 0

Maga Laan (magalaan) wrote :

When I do a recovery boot, followed by a resume normal startup:
I see this on the screen for one and half minute:

...
mounted /media/user/DOCS
mounted /media/user/TADA
mounted /media/user/DATA
A start job is running for dev-disk ... b2c.device (1 min 27s /1min 30s)

For some reason it will not mount /media/user/WORK like the rest. But after bootup the partition WORK is mounted

Maga Laan (magalaan) wrote :

I decided to check the information in /etc/fstab. The UUID of swap was incorrect. Gparted did not see the swap partition, so it had no UUID. I corrected that and entered the correct UUID in fstab and now it boots fine. Maybe it is caused because I share the swap partition with other Linux installations.

~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @9.993s
└─multi-user.target @9.993s
└─kerneloops.service @9.900s +17ms
└─network-online.target @9.899s
└─network.target @3.198s
└─NetworkManager.service @2.147s +1.050s
└─basic.target @2.144s
└─sockets.target @2.144s
└─uuidd.socket @2.144s
└─sysinit.target @2.142s
└─networking.service @1.520s +621ms
└─apparmor.service @1.390s +128ms
└─local-fs.target @1.389s
└─run-vmblock\x2dfuse.mount @9.984s
└─local-fs-pre.target @1.346s
└─systemd-remount-fs.service @1.338s +7ms
└─systemd-fsck-root.service @1.278s +58ms
└─systemd-fsckd.socket @202ms
└─-.slice @195ms

Changed in systemd (Ubuntu):
status: Incomplete → Invalid
Jef Spaleta (jspaleta) wrote :

okay thats specifically a vmblock-fuse service issue.
open-vm-tools-desktop package provides the
/lib/systemd/system/run-vmblock\x2dfuse.mount
which is the service that is taking so long.

This isn't a systemd generated mount from parsing fstab as I first thought.
It should be an explicit unit file on your system placed there and enabled by the open-vm-tools-desktop package.

And I'm not familiar enough with using vmware to suggest how to troubleshoot that particular service.
If you aren't using vmware tools.. you can probably disable that mount unit without loss of functionality.

But since open-vm-tools-desktop has a systemd specific mount file.. for the vmware-fuse mount point... I have to wonder.. how does this particular mount point get mounted when booting under upstart? Or did that fuse mount not get mounted before? I'm not seeing an equivalent upstart job or sysvinit script in trusty/vivid packaging of the open-vm-tools-desktop package that would have ensured the same mount attempt under sysV or upstart. Though I may have just not seen it. This looks like a vivid specific packaging addition to open-vm-tools-desktop. Someone who uses vmware regularly should look into that more closely.

Jef Spaleta (jspaleta) wrote :

ah bad swap partition UUID...

I missed that time out in your journal.txt.

Definitely see it now...

apr 25 00:42:47 kei systemd[1]: Job dev-disk-by\x2duuid-ec53629f\x2d3dea\x2d4baf\x2db0b3\x2d9065267acb2c.device/start timed out.
apr 25 00:42:47 kei systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ec53629f\x2d3dea\x2d4baf\x2db0b3\x2d9065267acb2c.device.
apr 25 00:42:47 kei systemd[1]: Dependency failed for /dev/disk/by-uuid/ec53629f-3dea-4baf-b0b3-9065267acb2c.
apr 25 00:42:47 kei systemd[1]: Dependency failed for Swap.
apr 25 00:42:47 kei systemd[1]: Job swap.target/start failed with result 'dependency'.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments