ok, thanks, I downloaded 4.50 windows version (which has 28.5 engine instead of 29.x) and will try to use it
setting the builtin-trust-anchors to trusted solved the certificate issue, but still doesnât work.
Pi-Hole6: *** check registry https://registry-1.docker.io/v2/
Pi-Hole6: import error: check url failed: Idle timeout - connecting
itâs the same with https://lscr.io and https://registry.hub.docker.com.
Tomorrow Iâm going to try with the other docker version to add a (hope correctly) pulled image
Yes, changes are related to built-in CA certificates which are not trusted by default, see Certificates Settings help page. From 7.20 after each ROS upgrade built-in CA certificates needs to be manually trusted as described in help page. You probably added container in some prev. ROS version, before upgrade, where such behavior was different (there was no SSL cert. validation on image fetch or built-in CA certificates was always trusted, not sure).
I have https://registry-1.docker.io registry URL set and I donât have any issues with any container I tried to add, also have Pi-hole added (in ROS 7.20.6). This error suggest that ROS has some connectivity issue to Docker registry or in general.
donât know why, but after some (many) retry it workedâŚnow, of course itâs pihole v6 that doesnât work 
IDK, my device is on same architecture (ARM64) and latest version worksâŚ
Try starting without old config, if you have mount for config donât mount it to check with initial config. Can't remember for sure, but I think old v5 config is not compatible with v6 and I needed to setup Pi-hole from scratch when I was migrating. Also config env. variables has changed, check Pi-hole docs.
I was aware of the changes. It seems that just 1 out of the 3 variable (the pwd) has changed.
After the container starts I canât reach the login page in the browser. it seems to timeout, but from the log nothing seems to fail. Iâm stuck before the hypothetical config incompatibility (it should work upword, I updated another pihole instance installed into a Raspberry and the connfig was just upgraded (in fact a v6 config shouldnât be importable into a v5), because I cantâ access the page where to import it. Iâm going to try again
I was not sure regarding config, migrated long time ago. I will still suggest to try with initial default config and access admin over http directly using container IP address, inital startup takes some time, so admin is not available immediately when Pi-Hole is started (depends on device performance). Here are changes related to env. variables.
it would be nice to be able to access it
If Pi-hole container is running and you can enter container shell with /container/shell <pihole_container_name>, then from shell you can enter command netstat -anl to get all listening ports and if command output has record 0.0.0.0:80 then some ROS configuration is blocking connection to Pi-hole http admin and it is not related to Pi-hole setup.
this is the output:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.54:80 192.168.1.6:54515 FIN_WAIT2
tcp 0 0 192.168.1.54:80 192.168.1.6:54516 FIN_WAIT2
tcp 0 0 :::80 :::* LISTEN
tcp 0 0 :::53 :::* LISTEN
tcp 0 0 :::443 :::* LISTEN
tcp 0 0 :::445 :::* LISTEN
tcp 0 0 :::445 :::* LISTEN
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 :::53 :::*
it should answer to 192.168.1.54.
the fact that 0.0.0.0:80 is present is still bad?
PS: opening the shell of the actual pihole5 working container and typing netstat results in âcommand not foundâ, so I canât even compare the two outputs
This list of listening ports seem to be ok, same as in my container.
It is strange that you can connect to v5 but not v6 if same VETH interface is used for both containers and not both containers are running at same time while using same VETH, try to troubleshoot with torch and sniffer to find out what is exactly happening. If different VETH is used for v6 container, check if VETH interface is added to bridge port and/or is there some firewall filter rule(s) that blocks traffic.
By default Pi-hole services are listening on any interface IP, since container has only single interface (VETH) that is not concern.
It is based on different base Linux layer image (v5 is Debian based, v6 Alpine) and it doesn't have package with netstat installed by default, you can try to install it using apt package manager - apt update && apt install net-tools but I think you will have same result, listen ports in container are not issue here.
P.S.
Noticed now:
Is v5 container running on same VETH while testing v6? That will not work because you have port conflict on same IP, use different VETH with different IP for v6 if that is the case.
Side note: If you want until 7.21, there is the new /app scheme, which allows you to bring up PiHole in less steps.
And another topic that been hijacked, where "docker built containers" turns into troubleshoot PiHole network config...
True that 
Yes, actually they share the same veth, isnât enough to just keep one stopped while the other running? they conflicts anyway?
sorry, my fault! but in my defense I was taken here by a casual concomitance of search terms (shame on you google! ehehhe).
Anyway, as far as I can see anyone have pihole issues on mikrotik, so any topic could easly turns into troubleshoot PiHole network configâŚand it does 
It should be ok if one is stopped, but who knows if there is some bug related to it, I never shared same VETH across containers to confirm behaviour. It easy to create additional VETH and try how it works when not shared.
yeah, trying thisâŚI forgot how struggling was adding a container 
from a remote image (now I remember why I used to manually download a local copy of the image from docker!). Itâs thousands attempts fighting against auth, connection and fetching layer errors
it must be something specific on the pihole v6 container configuration, because on the same new veth2 a new v5 container works perfectly