Your message dated Sat, 25 Oct 2025 15:47:24 -0400 with message-id <[email protected]> and subject line Re: Bug#934686: dockerd[3598]: Error starting daemon: error initializing graphdriver: driver not supported has caused the Debian Bug report #934686, regarding dockerd[3598]: Error starting daemon: error initializing graphdriver: driver not supported to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 934686: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934686 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: docker.io Version: 18.09.5+dfsg1-1 Severity: normal Dear Maintainer, The unit docker.socket has entered the 'failed' state with result 'service-start-limit-hit'. It works with kernel 4, but fails with 5 *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser 3.118 ii iptables 1.8.3-2 ii libc6 2.28-10 ii libdevmapper1.02.1 2:1.02.155-3 ii libltdl7 2.4.6-10 ii libnspr4 2:4.21-1 ii libnss3 2:3.45-1 ii libseccomp2 2.4.1-2 ii libsystemd0 241-7 ii lsb-base 10.2019051400 ii runc 1.0.0~rc6+dfsg1-3 ii tini 0.18.0-1+b1 Versions of packages docker.io recommends: ii ca-certificates 20190110 ii cgroupfs-mount 1.4 ii git 1:2.23.0~rc1-1 ii needrestart 3.4-5 ii xz-utils 5.2.4-1 Versions of packages docker.io suggests: ii aufs-tools 1:4.14+20190211-1 ii btrfs-progs 5.2.1-1 ii debootstrap 1.0.115 pn docker-doc <none> ii e2fsprogs 1.45.3-4 pn rinse <none> ii xfsprogs 5.0.0-1 pn zfs-fuse | zfsutils <none> -- no debconf information
--- End Message ---
--- Begin Message ---Vladmimir Stavrinov <[email protected]> writes: > The unit docker.socket has entered the 'failed' state with result > 'service-start-limit-hit'. > > It works with kernel 4, but fails with 5 > Hi Vladimir, First -- thank you for the clear, detailed report and for including the full system information. That made it very easy to see what’s happening. I completely understand the frustration: Docker has been working perfectly on your 4.x kernels, and suddenly with 5.2 it refuses to start. That kind of regression feels like a step backward, even when it’s not really a bug in the package itself. Here is what's going on: Docker needs a storage driver (sometimes called a graphdriver) to manage image layers and container filesystems. In older Debian setups—especially on kernels in the 4.x series—the default driver was often aufs, because it was stable, well-understood, and widely used in early Docker deployments. However, aufs was never merged into the upstream Linux kernel. It has always lived as an out-of-tree module. Starting around kernel 5.0, and especially by 5.2, most distributions (including Debian unstable/sid) dropped built-in support for aufs because: - It’s effectively unmaintained upstream. - The official replacement, overlay2, is faster, more secure, and fully integrated into the mainline kernel. - Carrying aufs as a DKMS module became increasingly fragile with each new kernel. Your system is trying to start dockerd using aufs (likely the default from your older config or inherited behavior), but kernel 5.2.0-2-amd64 simply doesn’t have aufs available—no module, no support. Hence: texterror initializing graphdriver: driver not supported And because the daemon fails immediately, systemd keeps retrying until it hits the start limit: textdocker.socket: Failed with result 'service-start-limit-hit' This isn’t a crash in Docker itself -- it’s Docker doing exactly what it should: refusing to start with an unsupported backend. Linux 5 fully supports overlay2, and it’s the recommended driver for modern Debian systems. All you need is a one-line config change. $ sudo mkdir -p /etc/docker $ sudo tee /etc/docker/daemon.json > /dev/null <<EOF { "storage-driver": "overlay2" } EOF Then restart the service: $ sudo systemctl restart docker You should now see: $ docker info --format '{{.Driver}}' overlay2 And everything should work exactly as before—often faster and with better snapshot performance. Why This Wasn’t Caught Earlier ------------------------------ Docker doesn’t auto-migrate storage drivers (for good reason—it would risk data corruption). So even though overlay2 has been the upstream default for years, systems that were set up years ago on aufs keep trying to use it unless explicitly told otherwise. Ideally docker would provide an error such as: Storage driver 'aufs' is not supported on this kernel. Consider using 'overlay2'. Not sure if it makes sense these days though, since the issue is kindof old and fresh installations are not affected by this. All the best, -rt
--- End Message ---
