Control: tags 848834 + moreinfo unreproducible Control: reassign 848834 docker.io Control: retitle 848834 fails to build stretch image in stretch docker Control: affects 848834 debirf
On Mon 2016-12-19 21:29:30 -0500, Antoine Beaupré wrote: > I have recently tried building a stretch image in a stretch docker > container. The build aborts with: > > I: Unpacking the base system... > W: Failure trying to run: chroot /tmp/minimal/root dpkg --force-overwrite > --force-confold --skip-same-version --install > /var/cache/apt/archives/adduser_3.115_all.deb > /var/cache/apt/archives/libapparmor1_2.10.95-8_amd64.deb > /var/cache/apt/archives/libcryptsetup4_2%3a1.7.3-3_amd64.deb > /var/cache/apt/archives/libip4tc0_1.6.0+snapshot20161117-4_amd64.deb > /var/cache/apt/archives/libkmod2_23-1_amd64.deb > /var/cache/apt/archives/libcap2_1%3a2.25-1_amd64.deb > /var/cache/apt/archives/libidn11_1.33-1_amd64.deb > /var/cache/apt/archives/libseccomp2_2.3.1-2.1_amd64.deb > /var/cache/apt/archives/dmsetup_2%3a1.02.137-1_amd64.deb > /var/cache/apt/archives/libdevmapper1.02.1_2%3a1.02.137-1_amd64.deb > /var/cache/apt/archives/systemd_232-8_amd64.deb > W: See /tmp/minimal/root/debootstrap/debootstrap.log for details (possibly > the package systemd is at fault) > > I attached the complete debootstrap.log. > > The container was built with the "debian:testing" image, which is: > > Linux 3e139afbcccd 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 > (2016-10-19) x86_64 GNU/Linux > > .... so fairly new. It's an "official" image, according to this: > > https://hub.docker.com/_/debian/ > > I am assuming the problem is not related to docker, but maybe that > assumption is flawed as well. To reproduce: > > sudo apt-get install docker.io > sudo adduser $(id -un) docker > newgrp > docker run -t -i debian:testing /bin/bash > apt-get update -qq ; apt-get install -y debirf sudo > cd /tmp > tar xfz /usr/share/doc/debirf/example-profiles/minimal.tgz > sudo -u nobody debirf make minimal hm, this reproduction step isn't possible in stretch, since docker.io isn't in stretch. It's not clear to me why you'd want to run debirf within docker anyway, since debirf is designed to run as a non-privileged user. but i tried it anyway, and i was unable to get past the "docker run" line: 0 dkg@sid:~$ docker run -t -i debian:testing /bin/bash docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"cgroup\\\" to rootfs \\\"/var/lib/docker/overlay2/e0801abba1fcdb2fb6dd685710127b1f797d98a6554e5da427dc2681afe9e1a4/merged\\\" at \\\"/sys/fs/cgroup\\\" caused \\\"no subsystem for mount\\\"\"". 125 dkg@sid:~$ fwiw, i also think you probably also want to unpack the profile .tgz as the user that's going to run debirf -- it looks like you're extracting the tgz as root, and then working in the profile as a non-priv user. > Justification for severity: I believe this falls in the category of > "makes the package in question unusable by most or all users" and > should be marked as "grave". Obviously, I can't test for all users' > environments and considering I heard reports from the maintainers this > was working in *sid*, I assume it *must* be working for other > users. This could be a docker-specific thing, but I actually doubt > that. So if someone can reproduce on a regular stretch system, this > should probably be bumped to "grave". I've done the standard build as a non-root user using the just-uplodaed 0.37 bugfix release, and it works fine, so i'm inclined to say this is a problem with docker (or perhaps with the docker image for debian testing? i don't really know how to attribute breakage inside docker images, but i welcome pointers or help in doing so). So i've reassigned this bug to docker, since it seems to be peculiar to that environment, though i'm unable to reproduce it myself because i can't get docker to behave as you describe. --dkg
signature.asc
Description: PGP signature
