http://bugzilla.suse.com/show_bug.cgi?id=1013619 http://bugzilla.suse.com/show_bug.cgi?id=1013619#c1 --- Comment #1 from Marcus Schaefer --- I tried the following to get decices: 1. vgscan --mknodes did not work 2. started udev in the container and repeated the procedure did not work 3. tried with udevsettle and udevd --daemon did not work any help is highly appreciated -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1013619 http://bugzilla.suse.com/show_bug.cgi?id=1013619#c3 --- Comment #3 from Marcus Schaefer --- Maybe also important. The container host system is Leap 42.1. The container itself is Tumbleweed. The docker version running on the host is: docker-1.12.1-19.1.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1013619 http://bugzilla.suse.com/show_bug.cgi?id=1013619#c4 --- Comment #4 from Aleksa Sarai ---

@Flavio: I wasn't sure how to contact the entire docker team via bugzilla. Thus feel free to send this to your team. If you can make sure this is not a docker but lvm problem also feel free to hand it over to the lvm team (if something like that exists)

Thanks

I've assigned it to containers-bugowner (which is the mailing list we have for the containers team). I'll take a quick look at this later today. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1013619 http://bugzilla.suse.com/show_bug.cgi?id=1013619#c6 --- Comment #6 from Aleksa Sarai ---

lvcreate -v -L 268 -n var systemVG

Archiving volume group "systemVG" metadata (seqno 1). Creating logical volume var Creating volume group backup "/etc/lvm/backup/systemVG" (seqno 2). Activating logical volume systemVG/var. activation/volume_list configuration setting not defined: Checking only host tags for systemVG/var. Creating systemVG-var Loading systemVG-var table (254:1) Resuming systemVG-var (254:1) /dev/systemVG/var: not found: device not cleared Aborting. Failed to wipe start of new LV. Removing systemVG-var (254:1) Creating volume group backup "/etc/lvm/backup/systemVG" (seqno 3).

Alright, so the reason this is happening is because /dev inside a Docker container is quite different to /dev on your host. /dev inside a Docker container is actually a tmpfs which has a bunch of things bindmounted into it (rather than being a full-on devtmpfs mount). This means that the /dev/systemVG directory won't be created in the container (it's just a tmpfs). Now, there are a couple of ways to handle this. To be honest, I'm not sure which is the safest. You can just straight-up bindmount /dev from your host into the container. While this might seem risky, /dev isn't namespaced in the kernel so AFAIK this should actually not affect how "safe" these operations are -- not to mention this is running in a privileged container anyway (which is only slightly better than chroot(2) in terms of separation from the host system). So you could try this: % docker run --privileged -ti -v /dev:/dev opensuse/dice:latest bash Another potential option would be to mount /dev as read-only and then only read-write the parts you want. But that wouldn't be automatic and you'd have to mess around with things quite a bit. The other option is to see whether Docker upstream will change --privileged containers to use a full devtmpfs. Unfortunately I don't think they'd like this change -- purely because of the security implications. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1013619 http://bugzilla.suse.com/show_bug.cgi?id=1013619#c7 --- Comment #7 from Marcus Schaefer --- Thanks much that's valuable information. I wasn't aware that in privileged mode /dev is not a full devtmpfs mount. So privileged allows creation of new device nodes but not in the origin of /dev. With that information I could run the container with a shared dev and new instance of udev to allow processing of the rules. That solved the problem and creates the nodes. On the other side it re-opens one of the reasons why I moved the build to the container. for people building on a host system which has lvm enabled I thought it could be separated from the host. but the required presence of udev and the lvm rules causes an lvm scan to find all existing volume groups on that system and in all containers on that system, which was actually the information I planned to hide from each other. hmm... but yes no longer your playground Thanks -- You are receiving this mail because: You are on the CC list for the bug.