Is there a guide or explanation anywhere about upgrading a pihole container instance running on a MT router? I have a fully working setup so don’t want to mess it up.
Is there a way to back it up, in case it doesn’t work?
bump
I’m upgrading Pihole regularly when update is avaiable (visible on web gui at bottom). How it breaks in your case?
I use it on hap ax3 with USB key inside.
I use cli for everything and I don’t download image from the router. I pull from my pc, save it as img file and send it to the USB key through scp.
After I create a new container without start it.
It take few minutes to be ready.
When everything is fine, I stop the old, start the new and just have less than 1 minute without dns server for the client.
Just because I use only one IP for client dns resolver. It’s possible to have 2 Ip for two containers and send theses 2 ip to the clients… Dns is a good protocol, client can easily switch between dns servers without any action.
Yes, you can set multiple DNS server IPs for DHCP network.
I tried the method of setting up a new container, pointing everything to the existing folders and variables, then turning off the old one and starting the new one.
I applied the container setup but didn’t start it. It failed to set up. I did not start the new container.
The old container now no longer works. I assume the new implementation overwrote the old folder. D’Oh!
I couldn’t backup the container folder - I sort of could by SMB, it skipped a few files, so it wasn’t a complete backup. For future info, how can I make a complete backup of a container folder?
This is not correct way to update container. You first need to delete old one (wait a bit to ROS delete its root dir) and create new one with same config, you cannot have 2 or more containers on same root-dir. I think ROS needs improvement for creating containers and not allow to create new one with same root dir and VETH interface (ok maybe shared VETH across containers can be used if containers with same interface doesn’t run at same time, but then starting container can be restricted if other container is already running) which already assigned to some other. I wrote container update script to automate this process, if you want that see here.
Also containers must have mounted directories if you want configuration (or other data) persistance after update, because monted dirs are not deleted with container and new container will run without loosing service configuration data, for Pi-hole here you can see for mounted volumes pointing to these directories (/etc/pihole and /etc/dnsmasq.d) where configuration is stored.
If you need Pi-hole DNS to be always avaiable while update is performing you can create 2 Pi-hole containers (with different root dir and mounts) and both VETH IP addresses set to DHCP network for DNS (like @dang21000 asked above) and update them one by one.
For Pi-hole configuration backup/restore you can use its Teleporter feature in GUI Settings section, you will not need to use this after each update if configuration dirs are mounted as mentioned above, but it’s good to have configuration backup if container storage gets corrupted and you need to create new instance on different disk or just if you want to revert some changes in Pi-hole config at some point.
Thanks Optio. That is all very useful and helpful info. The script is a nice solution.
In terms of the process, does your process keep all of the setting for the pihole (adlists, DNS settings, etc.) or do you need to run the teleporter pre and post update?
Script is cloning current container config (ROS container config, don’t mix with service (Pi-hole) config in container) into new, preserving service config in container it’s up to you how is container configured, as I wrote:
…you will not need to use this after each update if configuration dirs are mounted as mentioned above…
Also do not assign mount dir to be inside of container root dir, for eg. I have hierarchy:
usb1/containers/
<container1>
<container2>
...
usb1/containers/mounts/
<container1>/
<mount1>
<mount2>
<container2>
<mount1>
...
where container root dirs are in usb1/containers/ and mounts are in usb1/containers/mounts/ for each container (ofc. I don’t have root dir assigned to mounts dir in any container).
If currently you don’t have mounts assigned to Pi-hole, best solution is to backup its curent config using Teleporter, remove container, configure it with 2 mounts to point container dirs /etc/pihole and /etc/dnsmasq.d, create and start, then restore from Teleporter backup. Next container updates will have perseved Pi-hole configuration if new container have same mounts.
Many thanks for this. It is, and you have been, very helpful.