moby: Ubuntu 15.04 vivid can not start docker 1.7.0

root@vagrant-ubuntu-vivid-64:/var/lib/docker/devicemapper# service docker status -l
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2015-06-19 07:31:16 UTC; 12s ago
     Docs: https://docs.docker.com
  Process: 6704 ExecStart=/usr/bin/docker -d -H fd:// (code=exited, status=1/FAILURE)
 Main PID: 6704 (code=exited, status=1/FAILURE)

Jun 19 07:31:16 vagrant-ubuntu-vivid-64 systemd[1]: Started Docker Application Container Engine.
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 systemd[1]: Starting Docker Application Container Engine...
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 docker[6704]: time="2015-06-19T07:31:16.596667126Z" level=error msg="Udev sync is not supported. This will lead to unexpected behavior, data loss and errors. For more information, see https://docs.doc...age-driver-option"
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 docker[6704]: time="2015-06-19T07:31:16.596752652Z" level=error msg="[graphdriver] prior storage driver \"devicemapper\" failed: driver not supported"
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 docker[6704]: time="2015-06-19T07:31:16.596788016Z" level=fatal msg="Error starting daemon: error initializing graphdriver: driver not supported"
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 systemd[1]: Unit docker.service entered failed state.
Jun 19 07:31:16 vagrant-ubuntu-vivid-64 systemd[1]: docker.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

I am using vagrant , with ubuntu 15.04

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 86 (37 by maintainers)

Commits related to this issue

Most upvoted comments

@adamwalach

Summary

If your docker binary is statically compiled, it is unsupported and prevented from launching (by default) in 1.7.0. Prior versions have displayed warnings, that they ignored.

Do I lose all my containers?

Containers do not have to be lost.

You can build a dynamically linked binary, and continue using your existing images, with no extra work.

or

The follow flag can be added to your daemon flags: --storage-opt dm.override_udev_sync_check=true Either in /etc/default/docker or /etc/sysconfig/docker or wherever for your distro. This flag will bypass the denial, and allow you to docker save ... or docker push ... your images. In this way preserving them.

Switching storage driver

Once you have saved images, then you can rm -rf /var/lib/docker to start clean. If your docker binary is still statically linked, then devicemapper will be skipped as an option, as it does not support your current setup.

Otherwise, you can add the following flag to your docker daemon: -s overlay (or aufs, etc) This will explicitly choose another driver.

Saved images

Once you have a setup with a different storage driver, you can reload the images you saved or pushed, with docker load ... or docker pull ... respectively.

Here’s the explanation:

  • devicemapper storage driver is now impossible to use with a static binary (the one you get on Ubuntu when installing from the script), as explained above https://github.com/docker/docker/issues/14035#issuecomment-113469709 (for reference, this was introduced by #11412)
  • A change introduced by #11999 makes it that if you previously used a different storage driver that the one which is currently preferred, we used that older one instead.

The end result is that your system favors something else that devicemapper, but because /var/lib/docker/devicemapper/ exists, we are trying to use it nevertheless and fail because the binary is statically link.

In the end, removing /var/lib/docker/devicemapper/ will fix the issue, but I do think we need to patch that.

Cc @vbatts.

FYI I use Docker with overlay on Ubuntu with --storage-driver=overlay, yet mkdir /var/lib/docker/devicemapper && systemctl restart docker was sufficient to reproduce.

@jfrazelle has a point here: we should never even consider prior storage driver data when I ask for a specific --storage-driver.