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

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

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.

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.

@pandel

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.

@gtarnaras

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

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!

@gtardif

@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!

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. ;^)

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

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

@djs55

@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!

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

I am still getting an error after upgrading to 2.3.0.3 and rebooting my Mac. Running OS 10.15.4. Reverting to 2.2.0.5 fixes the issue but I would prefer to be running the latest stable build of Docker.

I can confirm that 2.3.0.3 does NOT work.

I wasn't able to test https://desktop-stage.docker.com/mac/stable/45487/Docker.dmg
as I'm on a "managed" system and the fix didn't appear to have been signed.

Downgrading back to 2.2.0.5 to get work done also caused a "Settings error":
" Settings version is too high for the application.
" Use the latest version or reset to factory defaults to continue.

@will-rkr

@will-rkr @andraxin Could you share reproduction examples to demonstrate the problems you're experiencing? I suspect they're slightly different to what @pandel originally reported above. If I can reproduce it in-house I'll have a much greater chance of fixing it.

@djs55

@djs55
I suppose for those of us still experiencing issues,
the problem may simply boil down to specific dm_xyz
modules missing. I notice that in your test example,
you modprobe from within the container. Is that safe?

On closer inspection, a vanilla linear mapping does work.
I'm trying to use a crypt target and get the following error
on 2.3.0.3 (while 2.2.0.5 works as expected):

$ docker run --rm -it --privileged alpine
/ # apk add cryptsetup
[...]
/ # dd of=img bs=64k count=0 seek=1k
[...]
/ # cryptsetup -vd /bin/ls luksFormat img
[...]
/ # cryptsetup -vd /bin/ls luksOpen img yay
device-mapper: reload ioctl on    failed: Invalid argument
Command failed with code -1 (wrong or missing parameters).

Here is a snippet from my docker-compose file. It's as simple as it gets and I confirmed that I do need the devices listed to make certain apps work. As usual, the gold standard is Linux host where everything runs out of the box. But my Mac was working pretty well up until the update.

The error I get with Docker post 2.2.0.5 is that /dev/mapper/control is not found. Let me know if I can provide any additional info.

...
- /var/run/docker.sock:/var/run/docker.sock
devices:
- /dev/fuse
- /dev/loop0
- /dev/loop-control
- /dev/mapper/control
cap_add:
- SYS_ADMIN
security_opt:
- apparmor:unconfined

@ALL - just to make my "It works for me!" statement clear: I need to use "modprobe nbd" from within the running container (to use qemu-nbd and kpartx) which worked flawlessly for my needs with the new testbuild - did not try 2.3.0.3 though. My mechanism also uses loopback devices for image mounting.

I cannot comment on any other way of using the devicemapper.

This is fixed in the latest Edge release, 2.3.2.0.

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

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

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

j0ju commented on May 15, 2020

pandel commented on May 15, 2020

gtarnaras commented on May 23, 2020

pandel commented on May 23, 2020

jonashoechst commented on May 25, 2020

pandel commented on May 25, 2020

andraxin commented on May 26, 2020

jonashoechst commented on May 26, 2020

djs55 commented on May 26, 2020

pandel commented on May 26, 2020

mat007 commented on May 27, 2020

will-rkr commented on May 30, 2020

andraxin commented on Jun 2, 2020

djs55 commented on Jun 2, 2020

andraxin commented on Jun 3, 2020

will-rkr commented on Jun 3, 2020

pandel commented on Jun 3, 2020

stephen-turner commented on Jun 26, 2020

docker-robott commented on Jul 26, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions