Debian:Buster "/dev/mapper/control - no such device" in using Docker Desktop 2.3.0.2

[pandel]

Hi!

Using /dev/mapper/control under Linux (Debian Buster standard image) gives following error:

root@3d0b7c16263b:/tmp# kpartx -a /dev/nbd0 /dev/mapper/control: open failed: No such device Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. Incompatible libdevmapper 1.02.155 (2018-12-18) and kernel driver (unknown version). device mapper prerequisites not met

root@3d0b7c16263b:/tmp# cat /dev/mapper/control cat: /dev/mapper/control: No such device

Even though the device file is there, it is not accessible or whatever. At least you get the forementioned error.

This does NOT happen using the same Dockerfile under Docker Desktop 2.2.0.5, so I have to downgrade Docker Desktop for now.

System is Mac OS Catalina 10.15.4.

Regards,
Holger

[j0ju]

I can confirm this behavior. At least in the 2.1.0.x and 2.2.0.x series cat /proc/devices contained

    [...]
    Block devices:
    [...]
    253 device-mapper
    [...]

And /dev/mapper/control (char, 20, 236) was usable.

In the linux kit kernel of the hyperkit VM there is no device mapper compiled in or available as a module.

  ~ $ docker run --privileged --pid=host --rm -it alpine nsenter -t 1 -m -u -n -i ash -
  / #  find /lib/modules/ -name "*.ko"  | grep dm.ko

This feature allowed unpack and pack of filesystem images. Packing was useful to create container images from filesystem images when the project does not offer tar.gz based images.

I vote for including this again.

[pandel]

Yes, absolutely necessary!

I build install images for Raspberry Pi inside Docker using my qcow2 modification (see PR: RPi-Distro/pi-gen#349) and am using NBD for mounting/unmounting dynamic disk images.

[gtarnaras]

Confirming here as well. The block device is missing. My use case is similar to @pandel's . I am creating raspbery pi images Docker desktop 2.3.0.2 (45183) and MacOS Catalina 10.15.4. Fast workaround is to downgrade docker deskop to the previous version.

[pandel]

@gtarnaras Yes, downgrade is an option, but leads to total Docker lock ups sometimes, at least with my setup.

[jonashoechst]

Full ACK here - we are developing (and using) PIMOD to extend single-board computer OS images with custom software.

With Docker for Mac it was easy to test local builds, would be nice to have this feature back. Thanks!

[pandel]

@gtardif / @ebriney ... Sorry to address you directly, but it is an urgent problem and I think it will bother much more users than the small group here! You simply cannot disable kernel features people are relying on in a standard Linux distribution! Please, please it is absolutely necessary!

[andraxin]

Got bitten by this regression this morning. As everyone here attests, the previous version worked just fine; then the upgrade came... Had I known, I wouldn't have upgraded.

Would've been nice to see this mentioned here; or whereever major changes are communicated.

And, yes: this needs to be fixed ASAP!

Thanks for the links to the previous version. I managed to find them on a second, apparently more thorough, attempt. ;^)

[jonashoechst]

I looked the old build number up in the homebrew cask repository. Cask doesn't offer a downgrade-option either, but offers a history: Homebrew/homebrew-cask@92be423

This link leads to the previous version: https://download.docker.com/mac/stable/43884/Docker.dmg

[djs55]

I've re-enabled the device mapper module in this build: https://desktop-stage.docker.com/mac/stable/45487/Docker.dmg . If you could try it and let me know if it works, that would be very helpful. If it doesn't work, could you provide a simple repro case that demonstrates the problem?

For example this works, but it's quite a minimal test:

$ docker run -it --privileged --pid=host justincormack/nsenter1
/ # ls /dev/mapper
ls: /dev/mapper: No such file or directory
/ # modprobe dm_mod
/ # ls /dev/mapper
control

[pandel]

@djs55 Hey David! Many thanks! I did try it just now and it worked perfectly! As my pi-gen build tools are based on a heavily modified qcow2 (qemu-nbd) mechanism I would have noticed it right from the start, if something would not have worked as expected :-)

I'll be using this build for now 👍 ! Great!

[mat007]

The fix has now been released in Docker Desktop Stable 2.3.0.3, I’ll go ahead and close this issue.