`migrate-storage-driver` hangs when have internet access but no DNS

[diablodale]

Describe the issue you are experiencing

How to improve migrate-storage-driver success?
Test probe 📡 for DNS and abort if not available instead of hanging forever when no DNS is available.

What operating system image do you use?

rpi4-64 (Raspberry Pi 4/400 64-bit OS)

What version of Home Assistant Operating System is installed?

17.1

Did the problem occur after upgrading the Operating System?

No

Hardware details

• RPi 4
• usb3 SATA adapter to SDD as data disk

Steps to reproduce the issue

Today I made a derp 🙃 when I attempted the migrate-storage-driver on my HA. I read the notes that it needed backup, internet access, etc. I ran the command, reboot, and waited ~2 hours. The HA was pingable, but nothing else.

The derp was that I use AdGuard as an HA addon app. That or any other DNS server that runs on HA is an easy way for the migration to fail. When the migrate reboots, HA OS gets DHCP from the LAN, which has the IP for the HA computer that usually runs AdGuard. But during this migration it isn't... no DNS available. Today's migration code does not progress or abort. It hangs forever.

I went to my DNS router by IP and saw zero traffic to the HA computer. And then I realized it was DNS. I pulled power from my RPi4 HA. Reconfigured my LAN router to use itself as DNS via DHCP. Plugged in HA RPi4 and immediately many Mbit/sec traffic and in a few minutes HA was up and running.

I suggest some test DNS probes after the initial reboot for migration. And if they fail then abort the migration instead of hanging forever. 👍

Anything in the Supervisor logs that might be useful for us?

I saw no logs about it have DNS problems. I saw only the few migration log entries showing success after I reconfig'd DNS.

Anything in the Host logs that might be useful for us?

no

System information

System Information

version	core-2026.2.1
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	aarch64
user	root
virtualenv	false
python_version	3.13.11
os_name	Linux
os_version	6.12.47-haos-raspi
arch	aarch64
timezone	Europe/Berlin
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4993
Installed Version	2.0.5
Stage	running
Available Repositories	2719
Downloaded Repositories	7

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 17.1
update_channel	stable
supervisor_version	supervisor-2026.02.1
agent_version	1.8.1
docker_version	29.1.3
disk_total	117.3 GB
disk_used	21.6 GB
nameservers	fd98:5c74:ff05:0:3e37:12ff:fe60:a29d, 2001:9e8:af0:de00:3e37:12ff:fe60:a29d, fd98:5c74:ff05:0:659b:30ba:89c2:9470, 192.168.2.1
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	rpi4-64
supervisor_api	ok
version_api	ok
installed_addons	AdGuard Home (6.1.0), Z-Wave JS (0.29.1), Terminal & SSH (10.0.1), ESPHome Device Builder (2026.1.5), SQLite Web (5.0.0), Home-Assistant-Matter-Hub (3.0.4), Tailscale (dev)

Dashboards

dashboards	4
resources	5
views	3
mode	storage

Network Configuration

adapters	lo (disabled), end0 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth6e27b7b (disabled), veth4cf587b (disabled), veth74cb7eb (disabled), vethadeeceb (disabled), vethfb5148a (disabled), veth3f6efca (disabled), vethaf645db (disabled), vethc68ca64 (disabled)
ipv4_addresses	lo (127.0.0.1/8), end0 (192.168.2.6/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), veth6e27b7b (), veth4cf587b (), veth74cb7eb (), vethadeeceb (), vethfb5148a (), veth3f6efca (), vethaf645db (), vethc68ca64 ()
ipv6_addresses	lo (::1/128), end0 (2001:9e8:af0:de00:9a7a:e123:dae7:c8e/64, fd98:5c74:ff05:0:659b:30ba:89c2:9470/64, fe80::ead6:a544:37e7:5920/64), docker0 (fe80::9c7d:14ff:fe48:6aa7/64), hassio (fe80::a8f4:7cff:fed0:8023/64), veth6e27b7b (fe80::d091:e6ff:fe42:1697/64), veth4cf587b (fe80::486b:8eff:fe88:29b7/64), veth74cb7eb (fe80::8803:f0ff:fe10:e67e/64), vethadeeceb (fe80::8cf:baff:fecb:7743/64), vethfb5148a (fe80::448c:b9ff:feca:d1c1/64), veth3f6efca (fe80::68c5:e6ff:fed6:38f8/64), vethaf645db (fe80::4429:99ff:fe41:999e/64), vethc68ca64 (fe80::ac41:13ff:feb9:1852/64)
announce_addresses	192.168.2.6, 2001:9e8:af0:de00:9a7a:e123:dae7:c8e, fd98:5c74:ff05:0:659b:30ba:89c2:9470, fe80::ead6:a544:37e7:5920

Recorder

oldest_recorder_run	February 7, 2026 at 9:39 PM
current_recorder_run	February 13, 2026 at 7:57 PM
estimated_db_size	454.41 MiB
database_engine	sqlite
database_version	3.49.2

Additional information

No response

[agners]

I suggest some test DNS probes after the initial reboot for migration. And if they fail then abort the migration instead of hanging forever. 👍

Hm, yeah not a bad idea.

What I wonder why systemd-resolved's fallback DNS did not kick in here (1.1.1.1 should be used if the DHCP provided DNS is not available). Or is your network or your provider maybe blocking direct DNS access? 🤔

[diablodale]

Logs and event times

I didn't record the exact times on 2026-02-13 of my hung storage upgrade and then dns fix and hard power cycle. It was afternoon and an hour or two between. Looking at the host and supervisor logs, I see...

My HA (RPi4) has no RTC so on reboot its datetime is 2025-06-25. We can look at the log lines before to imply things.
I see no 1.1.1.1 string anywhere in any log.
I see Booting Linux on physical CPU 5 times in the host log each with 2025 timestamps due to no RTC.
I see 3 "storage driver" entries on interesting timestamps.

Given some log research
host_2026-02-16T14-47-53.137Z.zip
I suspect...

• hung migration at ~15:46:00 because in the supervisor log line 7755 I see a jump in time from previous log entries and a series of s6-rc with no timestamps. Same time in the host log line 5947 I see many DNS problems.
• success migration ~17:12:00 because in supervisor log line 7966 I see Host system reboot required to apply Docker storage migration
• no attempt to use a 1.1.1.1 fallback. It seems to follow exactly how I have configured my LAN.
  • DHCP server is on router
  • AdGuard on HA (its IP) is the DHCP assigned DNS server
  • AdGuard uses router as upstream DNS for only local LAN domain name lookups: .local, .fritz.box
  • AdGuard uses rotation of 3 upstreams (google, quad9, 1111) for everything else.

/////////// host log entries ////////////////////////
// line 4130
2026-02-11 04:32:32.075 homeassistant dockerd[667]: time="2026-02-11T05:32:32.074998253+01:00" level=info msg="[graphdriver] using prior storage driver: overlay2"

// line 4886
2026-02-13 11:29:27.546 homeassistant systemd[1]: systemd-timedated.service: Deactivated successfully.
2025-06-25 17:17:42.559 homeassistant kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]

// line 5844
2026-02-13 15:46:23.945 homeassistant systemd-timesyncd[630]: Initial clock synchronization
// line 5861
2026-02-13 15:46:25.471 homeassistant dockerd[647]: time="2026-02-13T16:46:25.471786477+01:00" level=info msg="[graphdriver] using prior storage driver: overlay2"
// lines 5946-6233
many various DNS failures, retries, switching IPs and protocols, etc.
// line 6037
2026-02-13 15:46:42.959 homeassistant systemd-timesyncd[1482]: Initial clock synchronization

// line 6188
2026-02-13 16:12:35.692 homeassistant os-agent[531]: INFO: 2026/02/13 17:12:35 system.go:95: Storage driver set to overlayfs containerd snapshotter

// line 6325
2026-02-13 16:14:23.116 homeassistant kernel: hassio: port 5(veth32a7ec4) entered disabled state
2025-06-25 17:17:42.581 homeassistant kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]

// line 7279, notice the timestamp before "Booting" is not correct
2025-06-25 17:17:54.405 homeassistant systemd[1]: Started Notify NFS peers of a restart.
2025-06-25 17:17:42.599 homeassistant kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]

// line 8239, notice the timestamp before "Booting" is not correct
2025-06-25 17:17:53.498 homeassistant systemd-time-wait-sync[651]: adjtime state 5 status 40 time Wed 2025-06-25 17:17:53.496506 UTC
2025-06-25 17:17:42.589 homeassistant kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]

// line 9207
2026-02-13 18:02:08.076 homeassistant systemd-timesyncd[649]: Initial clock synchronization
// line 9347
2026-02-13 18:02:16.977 homeassistant systemd-timesyncd[1312]: Initial clock synchronization

Internet ISP/WAN

• I use a FritzBox 7590ax DSL wifi WAN router (I'll use the term router below) to create my home LAN and connect via DSL to the internet
• My ISP does not block or force any particular DNS servers. Even as I type AdGuard HA app is happily cycling through 1.1.1.1, google dns, and quad9. Germany tends to not force things like that on customers and every day ~6am the ISP assigns a new external IP address to the WAN router due to Germany privacy law.
• ISP and router provide ip4 and ip6 service.

HA

I run HA on a RPi4 connected to my router via ethernet. I run various integrations/apps including AdGuard.

DHCP/DNS Setup

• The router itself for its own needs is configured to use google dns using google's ip4 and ip6 addresses. It is not configured to fallback to those assigned by the ISP.
• Router runs DHCP service for ip4 and ip6.
• Router is the DHCP gateway and its IP is fixed at 192.168.2.1
• DHCP configured to issue same fixed IPs to several macs including the HA server (192.168.2.6)
• DHCP configured to announce the local DNS server as 192.168.2.6 (aka HA which runs AdGuard app)

AdGuard DNS

• local and fritz.box DNS domains use 192.168.2.1 (aka the router). This allows the router to answer dns queries for computers on the LAN in which it issued DHCP addresses.
• All other dns queries to go rotation of: 1.1.1.1, google, quad9

Upstream DNS

[//local/fritz.box/]192.168.2.1
tls://1dot1dot1dot1.cloudflare-dns.com
tls://dns.google
tls://dns.quad9.net

Bootstrap

8.8.8.8
8.8.4.4
2001:4860:4860::8888
2001:4860:4860::8844
1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001

Private reverse DNS

192.168.2.1

use private reverse DNS resolvers = checked
enable reverse resolving of clients ip addrs = checked

Encryption settings

enable encryption = UNchecked
enable plain dns = checked

DHCP settings

disabled