Arch Linux bootstrap-based Docker image build setup
I have recently come up with an Arch Linux Docker base image build setup (https://github.com/czka/archlinux-docker), based on bootstrap tarball. Compared to the shell script approach (https://wiki.archlinux.org/index.php/Docker#Build_Image), it has the benefit of enabling Arch Linux Docker image builds on non-Arch hosts, and does not require root.
What do you think of it? I tried getting some attention on Arch forum (https://bbs.archlinux.org/viewtopic.php?pid=1667108#p1667108) but no reply yet. Maybe I'm re-inveting the wheel? I was thinking not, as no similar solution is documented here on the Wiki. Please let me know.
In the forum topic I mentioned I'm asking abot 3 things I need to sort out in order to call the whole thing done. I'll appreciate some input.
docker0 Bridge gets no IP / no internet access in containers
I want to rewrite this section: based on my experience with systemd 232 and Docker 1.13, creating /etc/systemd/network/ipforward.network file as suggested by that section introduces problems where bridges created by Docker loose their IP addresses once all containers using those bridges are stopped, and don't regain the IP. Ektich (talk) 09:42, 2 March 2017 (UTC)
Storage driver section regarding overlay2
The wording of Arch Linux using overlay2 suggests that the default storage driver is overlay2. From what I can tell, the default storage driver is devicemapper. Perhaps the section should say that there is work being done to make overlay2 the default storage driver and reference a Github issue or something like that. --Dmp1ce (talk) 01:21, 2 April 2017 (UTC)
Storage driver devicemapper clarification
It is true that devicemapper in loopback mode should never be used outside of development but if a proper LVM volume is being used (no loopback), performance is not degraded in any way. Devicemapper non-loopback is the preferred local storage driver on CentOS and RHEL. The wording should probably be changed to say that devicemapper is acceptable to use but there should be a proper backing for it and not just a loopback LVM volume. --MrOwen (talk) 23:19, 31 October 2017 (UTC)
no connectivity between containers
I experienced that docker containers started with docker-compose can not connect to each other (even on published ports). For me it only helped to disable ip tables filtering for bridges (which is not a good solution as it omits docker security (icc flag useless)
# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"
Good to add solution for:
dockerd: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network
which is following that commands:
#!/bin/bash # # create docker0 bridge # restart docker systemd service # confirm new outgoing NAT masquerade is set up # # reference # https://docs.docker.com/engine/userguide/networking/default_network/build-bridges/ # sudo brctl addbr docker0 sudo ip addr add 192.168.42.1/24 dev docker0 sudo ip link set dev docker0 up ip addr show docker0 sudo systemctl restart docker sudo iptables -t nat -L -n exit(0)
tested and works for me solution found at 
- Yes, this worked for me. Please go ahead and add this info to the page. axper (talk) 09:06, 16 August 2018 (UTC)
I have had issues when a container required to forward X11, as it wasn't able to connect to display via unix socket...
The solution was to found here and it was to allow docker to connect via
$ xhost +local:docker
Maybe it would be worth to add a section in troubleshooting?