From ArchWiki
Jump to navigation Jump to search

Arch Linux bootstrap-based Docker image build setup

I have recently come up with an Arch Linux Docker base image build setup (, based on bootstrap tarball. Compared to the shell script approach (, 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 ( 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/ 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)

Is stable (instead of Edge) branch of Docker available?

Currently docker gives 17.05 which is the Edge branch. Stable branch should be 17.03. I guess the maintainer just assumed that most Arch users would like Edge version? --Franklin Yu (talk) 22:00, 17 May 2017 (UTC)

Root equivalent through other means than the docker group

I really wouldn't call myself good at docker so I don't feel confident enough to edit this myself. But as far as I've understood, the `root equivalent` warning in the Installation section should at least be added to the Remote API section and probably some others too. Or maybe not everywhere, but some sort of indication that the reader is playing with fire depending on how they configure docker. Powersource (talk) 06:38, 12 July 2017 (UTC)

Drop-in snippets instead of /etc/docker/daemon.json. Why?

Is there a reason for promotion of the systemd drop-in snippets in the Wiki page?

Not sure but recommends using /etc/docker/daemon.json to set the storage engine. This approach seems more appropriate to me. --Michaelmcandrew (talk) 12:15, 18 December 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

Aatdark (talk) 13:52, 22 December 2017 (UTC)

Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"

Good to add solution for:

dockerd[13737]: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network

which is following that commands:


# create docker0 bridge
# restart docker systemd service
# confirm new outgoing NAT masquerade is set up
# reference

sudo brctl addbr docker0
sudo ip addr add dev docker0
sudo ip link set dev docker0 up
ip addr show docker0
sudo systemctl restart docker
sudo iptables -t nat -L -n


tested and works for me solution found at [1]

—This unsigned comment is by Drathir (talk) 22:57, 9 January 2018‎. Please sign your posts with ~~~~!

Yes, this worked for me. Please go ahead and add this info to the page. axper (talk) 09:06, 16 August 2018 (UTC)