Open kshpytsya opened 6 years ago
I am trying to get kubler run in a remote docker. Is it supposed to work?
Sorry but using Kubler with a remote Docker daemon is not an option, at least not with some tinkering. The reason for that is that the first phase of the build process writes a rootfs.tar
to the host directory, which is then used later by the second phase. With a remote Docker daemon this will not work as expected as the file is written on the remote Docker host and not your local box.
Docker for Mac/Windows work around that problem by transparently mounting (parts of) the local host file system into the "remote" Docker VM on your host. So using sshfs or similiar to mount the Kubler dir on your Docker remote host should do the trick. Note that depending on the images you are building the rootfs.tar
may get rather large, so probably best to have the remote host in your LAN.
My dev machine is running Gentoo with custom kernel with which docker has always had various problems, so I chose to go with docker-machine/boot2docker/VirtualBox way.
Just in case you missed it, the Gentoo Docker ebuild checks and lists all missing kernel options upon install. Should be smooth sailing after fixing that.
Moreover, the paranoiac part of me believes this to be more secure.
As Docker access effectively equals root access on the host this is certainly a valid concern, but in that case an isolated VM really is your only option.
Thank you for the detailed explanation. I am aware of the kernel config checker in Docker ebuild, but since I use a non-standard CPU scheduler (PDS, nee BFS), I have never managed to get local Docker running over the course of years. Maybe now that is possible, but considering my security concerns, I am not up to that anyway. The "remote" docker created with "docker machine" is actually running on the same physical machine but inside a VirtualBox VM running boot2docker. Actually, this setup automatically mounts /home
directory of the host machine into /hosthome
directory inside the VM, so doing docker-machine ssh
and creating a symlink ln -s /hosthome/<user> /home
has been sufficient to have the build process advance further. I also had to add -userfetch
and -userpriv
(maybe the latter is unnecessary) to BOB_FEATURES
in kubler.conf
, as otherwise I was getting "Permission denied" error at the very first fetch done by emerge
. With these two fixes, the ./kubler.sh build kubler/glibc
build process has successfully ran to completion.
Maybe it would be possible to incorporate this logic into your system to make this automagic, or at least document it for the benefit of others trying to tread the same path I did.
Thanks for the feedback!
I also had to add -userfetch and -userpriv (maybe the latter is unnecessary) to BOB_FEATURES in kubler.conf, as otherwise I was getting "Permission denied" error at the very first fetch done by emerge
Portage's distfiles/
is also host mounted from <kubler>/tmp/distfiles
into build containers, might be an issue with the portage
user missing in the Docker VM though I currently don't see how exactly, as even if the user is missing a matching uid/gid
should suffice.
Maybe it would be possible to incorporate this logic into your system to make this automagic, or at least document it for the benefit of others trying to tread the same path I did.
No promises on automagic, but yea should at the very least be documented. I'll leave this open until the docs are updated. Soon(tm).
PS: You can also freely edit the project wiki, should be open for all Github user accounts. This particular bit should def. be mentioned in the main install docs though.
I am trying to get kubler run in a remote docker. Is it supposed to work? Note that I have repeated those steps several times within a day interval, and the failure is 100% reproducible. On the other hand, running it on local docker on Ubuntu in a VirtualBox seems to work ok (build is currently in progress far beyond the failure point reported here for remote docker). My dev machine is running Gentoo with custom kernel with which docker has always had various problems, so I chose to go with docker-machine/boot2docker/VirtualBox way. Moreover, the paranoiac part of me believes this to be more secure.