Closed ronakpandya7 closed 6 years ago
edannenberg
commented
6 years ago Hi,
--> remove kubler-bob-70864-19411, NO_CLEANUP env prevents this
This is just a notice that Kubler deletes the build container after a failed build and how to prevent this. The actual error message should be above that, can you please post a bit more of the build output?
ronakpandya7
commented
6 years ago Hello edannenberg,
Thank you for your reply.
edannenberg
commented
6 years ago Unmerging (1 of 1) net-misc/openssh-7.5_p1-r3... fatal: Failed to run image kubler/bob-core:20171128
Odd. This reminds me a bit of #121. Do you run with Docker overlay1 storage driver per chance? The output for the following 3 commands would be helpful:
$ docker version
$ docker info | grep Storage
$ cat /etc/os-releaseDocker Version:
Client: Version: 17.09.0-ce API version: 1.32 Go version: go1.8.4 Git commit: afdb6d4 Built: Tue Sep 26 22:24:58 2017 OS/Arch: linux/amd64
Server: Version: 17.09.0-ce API version: 1.32 (minimum version 1.12) Go version: go1.8.4 Git commit: afdb6d4 Built: Tue Sep 26 22:24:58 2017 OS/Arch: linux/amd64 Experimental: false
Storage Driver: overlay
NAME="Container Linux by CoreOS" ID=coreos VERSION=1576.4.0 VERSION_ID=1576.4.0 BUILD_ID=2017-12-06-0449 PRETTY_NAME="Container Linux by CoreOS 1576.4.0 (Ladybug)" ANSI_COLOR="38;5;75" HOME_URL="https://coreos.com/" BUG_REPORT_URL="https://issues.coreos.com" COREOS_BOARD="amd64-usr"
edannenberg
commented
6 years ago That would indeed suggest it is the same issue as mentioned above. As I can't reproduce this I can only give you some pointers you can try:
Double check the workaround for the issue is present in build.sh of kubler/builder/bob. I'm assuming it is if you cloned this repo recently.
Start an interactive build container and see if you can get any more details on what might be the problem:
$ kubler build -i kubler/bob
# kubler-build-rootThe build should fail again, but now you can poke around in the container after the build failed.
Edit: I'm still running Docker 17.06.2 so might also be an issue with a newer Docker release unless someone else can confirm it works for them with 17.09.0-ce
ronakpandya7
commented
6 years ago Thanks for the suggestions
edannenberg
commented
6 years ago but how can i change the docker storage driver from overlay1 to overlay2 ?
You can pass the desired storage driver as a Docker daemon option, most distributions provide an env like DOCKER_OPTS=--storage-driver=overlay2 for that.
An example on how to modify DOCKER_OPTS on coreOS can be found here
Creating a drop-in /etc/systemd/system/docker.service.d/10-storage-driver.conf:
[Service]
Environment="DOCKER_OPTS=--storage-driver=overlay2"..should do the trick.
ronakpandya7
commented
6 years ago I have changed docker storage driver to overlay2, it works but then it gives the following error:
fatal: Couldn't find build container for image mynamespace/nmap
edannenberg
commented
6 years ago Well, progress. :)
In such cases it helps to study the build sequence when the build starts:
*** generate build order --> required engines: docker --> required stage3: stage3-amd64-hardened+nomultilib --> required builders: kubler/bob --> build sequence: mynamespace/nmap
This would suggest that mynamespace/nmap has no image parents. If you compare that with the output from the blog page the output should look something like this:
*** generate build order --> required engines: docker --> required stage3: stage3-amd64-hardened+nomultilib stage3-amd64-musl-hardened --> required builders: kubler/bob kubler/bob-musl --> build sequence: kubler/busybox kubler/glibc mynamespace/nmap
I'm guessing you missed to configure the IMAGE_PARENT when creating the new image. Check the build.conf of your nmap image.
However even if it has no parents this should still work as the builder got created successfully.
$ kubler build kubler/glibcThis shoud give you a kubler/busybox and kubler/glibc image. If this works it's likely some misconfiguration for your image or namespace.
build.conf and mynamespace/kubler.confronakpandya7
commented
6 years ago $ kubler build kubler/glibc this build successfullly..
NMAP image build.conf file content:
Used build container, optional, default: value of DEFAULT_BUILDER of namespace kubler.conf
#BUILDER="kubler/bob"
Run build container in privileged mode, optional, default: false
#BUILD_PRIVILEGED=true
Mount a host directory in the build container during the build, uses standard Docker -v syntax, default: unset/none
!! There is a reason Docker does not allow this, consider the consequences regarding build repeatability !!
#BUILDER_MOUNTS=("${_KUBLER_DIR}/tmp/somepath:/path/in/builder")
Use BUILDER_MOUNTS from parent image(s)?, default: false
#PARENT_BUILDER_MOUNTS='true'
Fully qualified image id (i.e. kubler/busybox), optional, default: scratch
IMAGE_PARENT="scratch"mynamespace/kubler.conf file content:
AUTHOR="elttam elttam@local"
DEFAULT_BUILDER="kubler/bob"
BUILD_ENGINE="docker"Hello edannenberg,
Any update on this ?
edannenberg
commented
6 years ago Finally got some time today to look further into this and was also able to reproduce the problem. In your build.conf:
IMAGE_PARENT="scratch"
If you follow the blog this should be IMAGE_PARENT="kubler/glibc". After fixing that the build ran.
However as I said the build should have also worked with your current config, the reason it didn't was that Kubler expected a BUILDER= config in case the image has no parent, see busybox image for reference.
Assuming the DEFAULT_BUILDER in such cases makes sense, added a patch so either way is supported now.
edannenberg
commented
6 years ago I'm guessing this is resolved now. Feel free to reopen if you still have an issue with this.
Hello,
I am new to kubler and create one basic image of nmap by going through the following URL. https://www.elttam.com.au/blog/kubler/ Everything is working fine but the issue arise when i fire build command to build nmap image. kubler build -F mynamespace/nmap
ERROR:: fatal: Failed to run image kubler/bob-core:20171128 --> remove kubler-bob-70864-19411, NO_CLEANUP env prevents this
Please Help me out..