Didn’t for me unfortunately.
Ended up ditching virtualbox and using HyperV. Was a wise choice.
Far superior in terms of functionality and speed etc.
Yup, reboot of the host sorted it for me
Supervisor > System > Reboot Host
Hello everyone! I found myself in this problem too and I can’t solve it!
I also tried to do a new installation from scratch, but unfortunately I can’t even complete the installation because supervisor doesn’t have internet access!
Can anyone help me out?
In my case there were two issues:
- IP address of hassio VM was blocked by firewall.
Diagnostics:
ha > login
-
# ping 8.8.8.8
- check that ping goes well. -
# exit
- to leave shell
Solution: depends on your firewall/gateway soft/hardware.
- DNS requests to server were going from 172.17.0.1 IP which obviously internal DNS didn’t like.
Diagnostics:
ha > login
-
# ping 8.8.8.8
- should be alive, -
# ping yahoo.com
- should be allive too. - If
yahoo
ping doesn’t ‘fly’, then check dns with
# nslookup yahoo.com
. -
# exit
- to leave shell
Solution: fix DNS.
After that update went with flying colors.
I have the same problem after upgrading my firewall. All network settings are the exact same as before upgrading the firewall (same subnet, same server running DNS and DHCP). There are no outgoing firewall rules and no hints in firewall or DNS-logs.
When pinging www.google.com from therminal it gets replies.
When nslookup www.google.com i get this:
Server: 127.0.0.11
Address: 127.0.0.11#53
Name: www.google.com
Address: 142.250.74.100
I have the exact same problem on two different systems (Raspberry PI and NUC) running HA OS installation.
I’m out of ideas, please help!
How did you fixed DNS?
I’m using Armbian based on Ubuntu 20.04.4 LTS.
To fix DNS I added DNS servers to /etc/systemd/resolved.conf
. I have two own DNS servers, if you want you can specify nearest appropriate server (for example provider’s DNS or 8.8.8.8, 1.1.1.1, etc.)
...
[Resolve]
DNS=192.168.1.1
FallbackDNS=192.168.1.2
...
Then
systemctl restart systemd-resolved
had the same issue, a few moments ago. I changed the HA DNS (which was my router IP) to the Google DNS (8.8.8.8). That fixed my problem.
how have you decided to go about implimenting usb acess on hyperv for zigbee or z-wave?
This did the trick for me… Thanks
Hi there, could you elaborate on how you changed the DNS? Is this something you configure in your router, or in Home Assistant?
Where can you change this? I have the same problem but I don’t know where to start
Had the same issue on 2022.11.3, trying to update to 2022.11.4.
ha network info
showed “host_internet: false”,
tried ha network reload
and that fixed it. Weird, but was able to update now.
This worked for me!!! From CLI ran ‘ha network reload’ , this solved not being able to reach supervisor API but ‘unhealthy’ remained. Therefore did a reboot of my system and from CLI ran ‘ha supervisor restart’ and again a restart of home assistant… and that did the trick…
you are a genius! Thank you very much!
Putting in the DNS Records in the resolved.conf and then hitting ha network reload
did the tricks!! You guys saved me a lot of pain - big thanks!
I love yoooouu!
for me, I had my HAOS connected to my PC’s ethernet port because I had just finished setting it up and used my PC’s internet during the installation proccess. I needed to connect it to my router’s ethernet in order to install addons.
Solved. My router was giving each DHCP client a FILTERING DNS server 9.9.9.9 After changing the DNS server to 8.8.8.8 (Google, non-filtering) my home assistant booted correctly.
Tested 2x first with the wrong SSD then with the right SSD.
set DNS (in ha app network menu, not tweaking with resolv.conf via ssh…) to 1.1.1.1 did the trick… But strangely, when later, I tried to set it back to my router’s address which act as primary DNS and still it was working, even after reboot!
No idea,what this to-and-fro manoeuvre fixed but it fixed it.
I prefer by far this way so I have DNS control centralized in 1 place…
In my case I was getting the error of supervisor not having internet access when I was trying to recover add-on back-up.
Now it works flawlessly with original settings = router’s address