Failed to start daemon error initializing graphdriver driver not supported

Error starting daemon: error initializing graphdriver: driver not supported #2914

Docker 2.0.0.0 crashes. Just updated from the previous version.

• I have tried with the latest version of my channel (Stable or Edge)
• I have uploaded Diagnostics
• Diagnostics ID: AD0B9DFA-B7F0-4D33-92B9-E1E4E702635A/20181119215306

Expected behavior

Docker should start normally.

Actual behavior

Docker crashes before starting showing this:

Information

The problem appear with the latest update 2.0.0.0.
This is the error: «Error starting daemon: error initializing graphdriver: driver not supported«

• Windows Version: Windows 10 Professional
• Docker for Windows Version: 2.0.0.0-win78

Steps to reproduce the behavior

1. Updated Docker to 2.0.0.0-win78
2. Try to start the service
3. Crash

The text was updated successfully, but these errors were encountered:

After cold restarting the Operating System, a new error is displayed:

Diagnostics ID: AD0B9DFA-B7F0-4D33-92B9-E1E4E702635A/20181119232054

New error displayed:

Steps to reproduce the new behavior

1. Disabled Docker atuomatic restart in the settings
2. Operating System cold restart
3. Tried to start Docker (Crash)
4. Tried to restart Docker (Crash)

I got the same first error after restarting OS after upgrading Docker to latest version yesterday.

You can check the Hyper-V, i’ve got the same error and i fixed by fixing Hyper-V component

Which component? I have same error on fresh setup. v2.0.0.0-win78

I’m having this error too. Not sure what you mean by «fixing Hyper-V component» — i tried disabling & enabling hyperv in the windows features but still have this error.

I only get the issue when I’m logged into docker for windows. Restarting it and not entering my login information and it seems to be able to run some of the commands such as docker build just fine.

Trying to start an image asks me to log in.

Logging in without trying to start anything will instantly cause the error.

Only started when I upgraded to v2.0.0.0-win78 today.

having the same issue on my desktop, not on my laptop. Docker will start if I reset it, but Kitematic fails to find native virtualization. Maybe a change with windows?

Hyper-V itself is working just fine (tested with new image)

You can check the Hyper-V, i’ve got the same error and i fixed by fixing Hyper-V component

I disabled Hyper-V, restarted, enabled Hyper-V again, and the problem still persists.

I have several images that I can not access now because of updating to the latest version 2.0.0.0 win-78.

Please help us. Thanks.

Diagnostics ID: AD0B9DFA-B7F0-4D33-92B9-E1E4E702635A/20181119215306

So. I started Hyper-V Manager, went to Virtual Switch Manager, created an external switch, reset to factory defaults, stopped docker, killed the Docker for Windows and Docker.Watchguard processes, and restarted Docker. It started up.

Reset to factory defaults works, but every image is destroyed.
So always backup your images before upgrading.

Have you made any changes to your Daemon under Settings — possibly to move the data root folder or to change the storage driver?

Have you made any changes to your Daemon under Settings — possibly to move the data root folder or to change the storage driver?

It was only the upgrade, without any additional changes.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

Источник

Error initializing graphdriver while starting daemon by systemd on CentOS 7.2 #22685

Output of docker version :

Output of docker info :

Additional environment details (AWS, VirtualBox, physical, etc.):

Steps to reproduce the issue:

1. Install docker-engine on CentOS 7.2: yum install docker-engine
2. Start it: sudo systemctl start docker

Describe the results you received:

docker engine didn’t start.

Describe the results you expected:

docker engine starts.

Additional information you deem important (e.g. issue happens only occasionally):

journalctl —no-pager -u docker shows this error:

yum package info:

The text was updated successfully, but these errors were encountered:

It looks like you previously ran docker on this host with a different graph-driver;

Because of that, docker refuses to start, because it cannot automatically choose which graph-driver it should use. You need to set the -s daemon option, for example -s=overlay or -s=devicemapper to pick which one you want to use.

You can use a daemon configuration file ( /etc/docker/daemon.json )

To set daemon options.

I’ll close this issue, because this is not a bug, but feel free to comment after I closed

Thanks, @thaJeztah. I agree with this:

It looks like you previously ran docker on this host with a different graph-driver;

Another docker daemon was installed but uninstalled incompletely in the machine. I guess it caused the problem.

I’ve hit this issue by doing the following:

• upgrading a 1.12.3 that was using —live-restore to 1.13.1 (no issue)
• moving from a docker.service to a docker.service.d/override.conf file (Both file had the same ExecStart with the «-s devicemapper» option set.)
• systemctl daemon-reload (no error)
• rebooting to upgrade the kernel

dockerd didn’t start and I had this partition that I needed to umount /var/lib/docker/aufs && rm -rf !$ by hand after seeing that journalctl -xe said the same thing about graphdriver choices:

/dev/mapper/delve—vg-root on /var/lib/docker/aufs type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)

This should not have happened with the -s devicemapper being explicitly set.

@RRAlex did you verify the service actually saw the -s option? Note that when using an override / drop-in to override ExecStart , you have to explicitly reset the ExecStart , then set the new value, otherwise the value is appended, e.g.;

@thaJeztah I’m pretty sure it was running with the right options because, afterwards, docker was running with devicemapper without any further modifications to systemd.

Though I’ve only tested this once, I’ll come back if it happens again. cheers!

Simple fix :
nano /etc/docker/daemon.json

Save — restart Docker.

I am having same issue of starting docker. What I don’t follow is on three nodes.. via various steps that I did of restart or re-run install steps.. it works.. but the other four it does not.. but I have tried now for a few days and not been able to repeat success.. or better yet.. root cause.

Error: systemctl start docker -> /var/log/messages
Nov 11 11:30:45 icpworker01 dockerd: time=»2018-11-11T11:30:45.802366532-05:00″ level=info msg=»scheme «unix» not registered, fallback to default scheme» module=grpc
Nov 11 11:30:45 icpworker01 dockerd: Error starting daemon: error initializing graphdriver: overlay2: unknown option dm.thinpooldev
Nov 11 11:30:45 icpworker01 systemd: docker.service: main process exited, code=exited, status=1/FAILURE

I guess I am just not seeing and understanding the root cause here.

@penguinpages looks like you configured options for the devicemapper storage-driver, but did not specify that the daemon should use the devicemapper storage driver.

So, what happens is that (if no storage-driver is specified), the daemon automatically selects the best available driver, which is «overlay2» on most current distros.

However, since the options you specified are specific for devicemapper , the daemon refuses to start, because those options are not valid for the overlay2 storage driver.

If possible, I would also recommend using overlay2 instead of devicemapper (the devicemapper storage driver is marked «deprecated», so will be removed in a future release).

To resolve your problem;

Option 1. (recommended) use the overlay2 storage driver, and remove the devicemapper configuration

Also the easiest approach; given that you have no other options configured in your daemon.json , you can simply remove the daemon.json file, and start the docker service.

If you do have other options set in your daemon.json ; remove the storage-opts from your daemon.json

Option 2. Override the automatic storage-driver selection, and specify that «devicemapper» should be used

If you have a specific reason to use devicemapper, and want to continue using it; Add «storage-driver»: «devicemapper» to your daemon.json (see the example in the dockerd reference documentation ).

In your case, the daemon.json then should look like this;

I am new to docker.. so trying to wrap my head around referance design best practices.
What I undestand is their are two volumes needed for docker.. one is for docker deployment of containers (tear down file space). Where containers are deployed.. have scratch but no other real write capabilties (and so IO and capacity sizing is lower for this/these volumes). They are dedicated and mapped to each individual worker or master. And I was using the IBM noted guide that underpinned these as LVM so I could as needed inject more «disk» to underpin more IO as customer would have scale up needs.

The second peice of any docker disk subsystem is the «persistant disk». I have an actual customer where they migrated a datawhere house to containerized version and performance was TERRIBLE.. so much they scrapped the project and moved back to physical systems. But looking at the design it was all about this persitent disk component. A heavy IO, container, and one needing capacity, lives and dies by this design component.

I am still stuck on step one of «What to do for best practice of tear down container volume» but was heading down the path of iSCSI (via the free product IBM Spectrum Control) to automate this and provide performance (in conjunction with iSER for iSCSI). But.. still wrapping head around things so open to constructive redirection of methodology.

Источник

Arch Linux

You are not logged in.

#1 2016-02-24 22:52:14

[SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Hi, I failed to find any info anywhere about this issue so here I am.

I first reported the issue to docker people who said it might be an incompatibility with Go and to point it to you in case it’s the problem (they are investigating my issue too).

To summarize: I have a fresh ArchLinux install, almost nothing going on. I install docker through. I run it’s hello world test. It fails. I discovered this while trying to install Discourse, but apparently it’s Docker or devmapper which fails to «register layer».
It looks like this:

I tried it after reinstalling completely docker, still fails.
I tried to restart the daemon with no success.

(not sure if it’s the right subforum, I can’t find one which is about specific packages)

Last edited by klaim (2016-02-27 01:37:02)

#2 2016-02-25 00:19:31

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

A few things to try (first make sure your user is in the docker group or you are running the docker commands with sudo or as root):

1. Stop Docker, delete /var/lib/docker, restart and then try pulling the image again. Also try another common image such as ubuntu or busybox. Frequently just wiping /var/lib/docker does the trick.

2. Stop Docker, then start from the command line (see /usr/lib/systemd/system/docker.service for the normal options), but set the storage driver option to overlayfs (default is devicemapper) with ‘-s overlayfs’ and run from the command line. Try the image pulls again and see if that changes anything.

Last edited by firecat53 (2016-02-25 00:21:09)

#3 2016-02-26 01:21:51

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Thanks for your time!

A few things to try (first make sure your user is in the docker group or you are running the docker commands with sudo or as root):

My login is part of the docker group and I use sudo too.

1. Stop Docker, delete /var/lib/docker, restart and then try pulling the image again. Also try another common image such as ubuntu or busybox. Frequently just wiping /var/lib/docker does the trick.

I did that already before because it was suggested in some documentations or some answers to other issues.
It was not a success.
I just tried again after updating everything (because there is a new version of the docker package that someone pointed on github that it could have fixed it).
It was not a success either.

2. Stop Docker, then start from the command line (see /usr/lib/systemd/system/docker.service for the normal options), but set the storage driver option to overlayfs (default is devicemapper) with ‘-s overlayfs’ and run from the command line. Try the image pulls again and see if that changes anything.

If I understand correctly, the command I must run is

If I run just this (with sudo) I get

If I add ‘-s overlayfs’ I get the same result.

Then I tried to modify the .service file by just adding these arguments to the original start command.
I started docker through systemctl, then got this error:

‘journalctl -u docker’ shows:

I return docker’s service file to it’s initial state now.

Basically, no progress as overlayfs seems to not work as is with docker.

Last edited by klaim (2016-02-26 01:27:51)

#4 2016-02-26 01:39:16

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

It was suggested on GitHub issue comments that I try the very new version which fix a compatibility issue with the Go version used by docker, but it seems unrelated to my problem which persists: https://github.com/docker/docker/issues/20653

#5 2016-02-26 03:04:28

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Sorry, I didn’t test before I wrote The overlay module needs to be loaded first. Although I’m still not sure why the default devicemapper storage driver isn’t working for you. What filesystem are you using? I can’t test the overlay storage driver because I’m using BTRFS and that’s not supported. You need to be using something like ext4 as the ‘backing filesystem’.

Try this first and see what errors it throws:

#6 2016-02-26 21:44:55

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Sorry, I didn’t test before I wrote The overlay module needs to be loaded first. Although I’m still not sure why the default devicemapper storage driver isn’t working for you. What filesystem are you using?

I know almost nothing about linux filesystems, unfortunately.

I can’t test the overlay storage driver because I’m using BTRFS and that’s not supported. You need to be using something like ext4 as the ‘backing filesystem’.

I do not know how to check the ‘backing filesystem’?

Try this first and see what errors it throws:

Looks like argument is ignored:

I have no idea what this means.

Last edited by klaim (2016-02-26 22:30:33)

#7 2016-02-26 23:04:01

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Wow, what kernel are you using?? That might be part of the problem. You’re missing the ‘nf_nat’ module (see the error for devicemapper), and the kernel you’re using doesn’t have the overlayfs module available. You’re going to have to either switch kernels (stock Arch kernel works fine) or learn how to compile a kernel with the correct modules

You’re using ext4 which is fine for use with devicemapper or overlayfs.

#8 2016-02-26 23:10:25

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

Wow, what kernel are you using?? That might be part of the problem. You’re missing the ‘nf_nat’ module (see the error for devicemapper), and the kernel you’re using doesn’t have the overlayfs module available. You’re going to have to either switch kernels (stock Arch kernel works fine) or learn how to compile a kernel with the correct modules

I have no idea why there would be an unusual kernel, but this is a Kimsuffi (OVH) box so maybe the inital image was modified. Onced installed I upgraded the whole thing but never thought about upgrading a kernel (I thought it was automatic with pacman upgrade?)
Anyway, I’ll look for how to switch kernel then.

#9 2016-02-26 23:19:45

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

I don’t know what is happening. Still searching for how to change kernel.

#10 2016-02-27 00:51:08

Re: [SOLVED] Docker’s Hello-World test fails after fresh ArchLinux install

It was indeed the kernel version.
I had to learn on-the-fly how to install an image and then how to setup grub to actually boot with it (I didn’t know it was grub doing this. )

╰─$ sudo docker run hello-world
Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
03f4658f8b78: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Status: Downloaded newer image for hello-world:latest

Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the «hello-world» image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
https://hub.docker.com

I will now proceed to try to (finally!!) install my discourse instance.

BTW, would there be a way to automatically detect this kind of issues better in the future?

Источник

Thanks for your time!

My login is part of the docker group and I use sudo too.

I did that already before because it was suggested in some documentations or some answers to other issues.
It was not a success.
I just tried again after updating everything (because there is a new version of the docker package that someone pointed on github that it could have fixed it).
It was not a success either.

If I understand correctly, the command I must run is

 /usr/bin/docker daemon -H fd:// 

If I run just this (with sudo) I get

 FATA[0000] No sockets found 

If I add ‘-s overlayfs’ I get the same result.

I tried:

 
╰─$ sudo docker daemon -s overlayfs                                                                                               1 ↵
ERRO[0000] Failed to GetDriver graph overlayfs /var/lib/docker
FATA[0000] Error starting daemon: error initializing graphdriver: driver not supported

Then I tried to modify the .service file by just adding these arguments to the original start command.
I started docker through systemctl, then got this error:

╰─$ sudo systemctl start docker
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

‘journalctl -u docker’ shows:

Feb 26 02:24:12 klaimslab systemd[1]: Starting Docker Application Container Engine...
Feb 26 02:24:12 klaimslab docker[27819]: time="2016-02-26T02:24:12.793512136+01:00" level=error msg="Failed to GetDriver graph overlayfs /var/lib/docker"
Feb 26 02:24:12 klaimslab docker[27819]: time="2016-02-26T02:24:12.793637730+01:00" level=fatal msg="Error starting daemon: error initializing graphdriver: driver not supported"
Feb 26 02:24:12 klaimslab systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 02:24:12 klaimslab systemd[1]: Failed to start Docker Application Container Engine.
Feb 26 02:24:12 klaimslab systemd[1]: docker.service: Unit entered failed state.
Feb 26 02:24:12 klaimslab systemd[1]: docker.service: Failed with result 'exit-code'.

I return docker’s service file to it’s initial state now.

Basically, no progress as overlayfs seems to not work as is with docker.

Last edited by klaim (2016-02-26 01:27:51)