[v9.8] Update failed on RPi4 - On RPi3 went fine

[master-kw]

Creating a bug report/issue

• [x] I have searched the existing open and closed issues

Required Information

G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=8 G_DIETPI_VERSION_RC=0 G_GITBRANCH='master' G_GITOWNER='MichaIng'

• bookworm 0
• Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• RPi 4 Model B (aarch64)
• original RPi4 power supply
• WD RED SA500 SSD

When starting "dietpi-update", it fails. I have a similar test client on RPi3, it went through

Bug report

[. ]curl: (6) Could not resolve host: raw.githubusercontent.com [FAILED] DietPi-Update | Downloading pre-patches

• Command: curl -sSfLO https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/pre-patches [ INFO ] DietPi-BugReport | Generating informative command outputs, please wait... [ OK ] DietPi-BugReport | Downloading pre-patches [ OK ] DietPi-BugReport | Packing upload archive [ .. ]* Could not resolve host: ssh.dietpi.com
• Closing connection 0 curl: (6) Could not resolve host: ssh.dietpi.com
• Could not resolve host: ssh.dietpi.com
• Closing connection 1 curl: (6) Could not resolve host: ssh.dietpi.com [FAILED] DietPi-BugReport | Sending bug report
• Command: curl --connect-timeout 8 --retry 1 --retry-delay 4 -sSvT 06dde672-6f57-47bf-94c2-1bf8642eb94b.7z sftp://dietpi-survey:upload2dietpi@ssh.dietpi.com:29248/bugreport/ [FAILED] DietPi-BugReport | Unable to continue, DietPi-BugReport will now terminate.

Press any key to continue... /boot/dietpi/func/dietpi-globals: line 963: /tmp/G_EXEC_LOG: No such file or directory [FAILED] DietPi-Update | Unable to continue, DietPi-Update will now terminate.

Regards, Oliver

[Joulinar]

Could not resolve host: raw.githubusercontent.com

DNS resolution is not working on your system. You are using an own DNS server like PiHole or AGH?

[master-kw]

Yes, I do and still checked this out. Like I said, with the similiar configuration the RPi3 went through.

[Joulinar]

do you use Docker to host your DNS or was it installed from dietpi-software? And are you using STATIC IP or DHCP? Which DNS server has been set?

[master-kw]

Docker and DHCP with fixed IP. Local DNS is set to AGH

[MichaIng]

Hmm, the update stops the docker.service, but not the containers themselves. So AGH should still be reachable. But you can check with:

ss -tulpn

Maybe also AGH logs contain some hint?

[Joulinar]

Local DNS is set to AGH

As a best practice, I would not do that. You can set a public DNS within DietPi own network configuration. Usually there is nothing that should be relevant to be counted as Ad. Except you are running a desktop + browser.

[master-kw]

Sorry guys, what a shame. Of course, it can't work. I basically sawed off the branch on which I sit.

RPi3 was regular client…

PS: DNS client is set only to LAN

[MichaIng]

You mean just an AGH configuration issue, so that it could not be used by the host?

[master-kw]

Yes, DietPi/AGH cannot update itself at the same time and switch off the service (Docker) that regulates DNS access. ;-)

Forgot to temporarily change the DNS port in the router

[MichaIng]

Ah hmm, as said docker.service should not shut down network access to the containers or the containers themselves (should it?), but only provide the socket and API for managing the containers 🤔.

[master-kw]

I run AGH as Docker container and set its IP as the local DNS server (FritzBox). So if the RPi4 stops docker.service the DSN server is not in operation and failed.

The RPi3 - as an 'outside client" - worked fine because it still has access to the Internet while the 'DNS client' is running

Or am I still going wrong? Everything's fine with DietPi. :)

[Joulinar]

my recommendation, on the RPI4 hosting AGH, use a STATIC IP and a public upstream DNS provider within DietPi network configuration.

[Joulinar]

Ah hmm, as said docker.service should not shut down network access to the containers or the containers themselves (should it?), but only provide the socket and API for managing the containers 🤔.

Nope, all containers are stopped as well. Juste tested on my system

Oct 18 13:23:19 DietPiProd systemd[1]: Stopping docker.service - Docker Application Container Engine...
Oct 18 13:23:20 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:20+02:00 [SERVER] INFO: Shutdown requested
Oct 18 13:23:20 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:20+02:00 [SERVER] INFO: Called signal: SIGTERM
Oct 18 13:23:20 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:20+02:00 [SERVICES] INFO: Stopping nscd
Oct 18 13:23:20 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:20+02:00 [SERVER] INFO: Stopping all monitors
Oct 18 13:23:20 DietPiProd 77425607c989[10507]: [10/18/2024] [11:23:20 AM] [Global   ] › ℹ  info      PID 169 received SIGTERM
Oct 18 13:23:20 DietPiProd 77425607c989[10507]: [10/18/2024] [11:23:20 AM] [Global   ] › ℹ  info      Stopping.
Oct 18 13:23:22 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:22+02:00 [DB] INFO: Closing the database
Oct 18 13:23:24 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:24+02:00 [DB] INFO: SQLite closed
Oct 18 13:23:24 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:24+02:00 [CLOUDFLARED] INFO: Stop cloudflared
Oct 18 13:23:24 DietPiProd 2362e1470d13[10507]: 2024-10-18T13:23:24+02:00 [SERVER] INFO: Graceful shutdown successful!
Oct 18 13:23:24 DietPiProd dockerd[10507]: time="2024-10-18T13:23:24.239161675+02:00" level=warning msg="ShouldRestart failed, container will not be restarted" container=77425607c989c25e9d4b47ce2ad007ef3219c09b92d0aba2ec4603234112bf2f daemonShuttingDown=true error="restart canceled" execDuration=50h39m1.200334658s exitStatus="{0 2024-10-18 11:23:24.144974601 +0000 UTC}" hasBeenManuallyStopped=false restartCount=0
Oct 18 13:23:24 DietPiProd dockerd[10507]: time="2024-10-18T13:23:24.267189286+02:00" level=warning msg="ShouldRestart failed, container will not be restarted" container=2362e1470d13fe8e8928cd3aef8959d5822e5d67c354b61c9424774a8c0d7287 daemonShuttingDown=true error="restart canceled" execDuration=49h37m26.901110194s exitStatus="{0 2024-10-18 11:23:24.179706842 +0000 UTC}" hasBeenManuallyStopped=false restartCount=0
Oct 18 13:23:25 DietPiProd systemd[1]: docker.service: Deactivated successfully.
Oct 18 13:23:25 DietPiProd systemd[1]: Stopped docker.service - Docker Application Container Engine.
Oct 18 13:23:25 DietPiProd systemd[1]: docker.service: Consumed 5min 24.690s CPU time.

[MichaIng]

Ah interesting, maybe this also depends on container settings, I remember there was this --restart policy option.

[sureshk75]

Yes, DietPi/AGH cannot update itself at the same time and switch off the service (Docker) that regulates DNS access. ;-)

Forgot to temporarily change the DNS port in the router

I'm in the middle of restructuring my network. Like you, I'm obsessive about keeping all my devices up-to-date (it's an OCD thing!), and I’ve temporarily bricked my network during updates because dependencies like Pi-hole, DHCP, etc., went offline during the process, causing update failures and hours of recovery. This time around, I’m dedicating a Pi 4 just for the network essentials, and I plan to keep my hands off after it's set up by limiting remote access. Fingers crossed that 'out of sight, out of mind' works! :P

[MichaIng]

Our bare metal Pi-hole, AGH and Unbound services are not stopped during updates, nor any other services we control which might be needed for the update itself, like SSH, VPN and other remote access methods.

I am sure, for Docker containers, there is also a way to keep them running, even when the Docker daemon is stopped, but it might then be needed as well to start them in a different way, when starting the Docker daemon does not do that in the same turn.

When the DNS of the host itself is shut down during an update attempt, it will abort early, just like it happened for OP. So no hours of recovery needed, just switching to a public DNS provider, which can be done right from the error handler menu. However, if e.g. the communication service (SSH, VPN, Remote.It, ...) is shut down while running the update through it, it might cause indeed some more recovery steps, like reconfiguring APT packages or running apt --fix-broken install, depending on at which stage the connection and related shell session was terminated.

[Joulinar]

Personally I run pihole (DNS + DHCP) on a RPI4 as standard DietPi installation and I'm doing regular updates without any issues. Never broke my system on that. Important is to have the RPi not pointing to pihole. I'm using Quad9 as glob public DNS on that device.

[master-kw]

use a STATIC IP and a public upstream DNS provider within DietPi network configuration.

I did so and it works fine! 😃

[Joulinar]

Ok going to close the issue for now. Feel free to reopen if needed.