And you mentioned time setting before - is the date correct? ssl connections fail if the date is a long way out.
date
yes, the date is correct (or it was when I tried that install the first time!). I even tried reinstalling using an old build (5.13), which (sort of) works… unless there is something going on with the firmware I’m unaware of?
It at least will load the to the Home Assistant command line and I can log in as root. However, Home Assistant is not loaded and the “preparing” page hasn’t changed for 6 hours. Looking at the supervisor logs shows an error for Syncworker.
INFO (Syncworker_1) [supervisor.docker.interface] Downloading docker image homeassistant/raspberrypi3-homeassistant with tag 2021.6.6.
ERROR (Syncworker_1) [supervisor.docker.interface] Can't install homeassistant/raspberrypi3-homeassistant:2021.6.6 -> 500 Server error for hottp+docker://localhost/v1.4/images/create?tag=2021.6.6&fromImage=homeassistant%Fraspberrypi3-homeassistnat: Internal Server Error ("Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)").
seems like the same issue as before… has anyone else tried a clean install of 6.1 on a pi3+? It seems to me that wherever it’s reaching out for 6.1 is broken…
1 Like
It really seems like this is a dns issue. Is there a way to change the default DNS for these docker containers?
Yet another update:
I happened to have an old image of 4.15 in my downloads folder on an old computer. I flashed it to the same SSD… and it WORKS.
now I am running Core and Supervisor version 6.6, but on Hassos 4.15. I tried upgrading through the cli as root but when i type any version for update (ha os update --version 5 or 6, or even 4.20) it says "Error: Don’t have a URL for OTA updates.
Further, when I am prompted in the dashboard to update to 6.1 and click update, the system appears to begin updating just fine until it goes to reboot and never loads (black screen with no way to interact with it)- the issue I had in the first place when I mentioned in the first post that my “system was hosed”. I had assumed something in my setup caused the update to break the system, but now it appears the issue is consistently reproducible and an issue with 6.1 itself.
I wonder if these are DNS related? Is there a naming change or something different between the versions that is causing it to error out?
By the way, are you not running WireGuard or PiHole or something which would alter your DNS request or block some access?
@ezankel, I asked this, because there was something similar in another issue when doing docker pull.
No, unfortunately. I initially suspected something like that but the only ad blocking I had was on my old home assistant (Adguard). Since this issue began, I have completely reset my router and (obviously) the pi as well.
This is a very simple setup with just a pi3b+ plugged (ethernet cord) into a Netgear r6700 router. I’ve tried swapping the cable as well. Primary DNS is 1.1,1,1 and secondary is 8.8.8.8. All QOS settings off. There could be some setting I don’t know about, but I’m at the limit of my knowledge with this.
The router is acting as the dhcp, and I have tried both allowing it to provide whatever ip address it wanted and also reserving a specific one for the pi. No change.
I’m not sure what changed between 4.15 and newer versions.
Edit: Any chance this has something to do with it? Any possibility that the error in the install script was reintroduced? Rpi3 with SSD, won't boot after OS update from 4.17 to 4.18 · Issue #1024 · home-assistant/operating-system · GitHub
I see your point. I’ve check the github repo, but I am not sure what is included in the final release of 6.0 and 6.1.
The bug what you referred has been fixed after 4.18 as I can see, back in last November. There is a recent change at the same part of the script has been changed recently in the dev branch changing the ext4mount to load. I would open an issue on Github if you cannot update from 4.15 to the latest (I guess 6.1) it might be a syntax error there. (The previous issue what you referred to was a typo with an extra ".)
But back to your original issue regarding unable to fetch the docker image. That is quite weird. The person who posted the issue previous experienced the same, and logged it quite well, but it is a bit unknown why it has happened.
You can try to drop the 1.1.1.1 and 8.8.8.8 DNS servers and just use the one provided by your ISP and test with that as well, maybe that fixes.
Or by any chance does your ISP has any sort of site verification, protection feature? I used recently Vodafone Italy’s service and they block some sites automatically until you are not saying that it is safe. They blocked a company’s website what I had to access for a software what I use for work.
I’ll open a bug, as this is consistently reproducible.
Right now I have 4.15 up and running nearly perfectly off my SSD with the latest 6.6 core and supervisor. I’ve made a full backup, and will change the DNS and attempt to load 6.1 again when I get home. Tried updating last night and it failed and reverted back to 4.15.
I am unsure what specific sites I should ask my ISP if they are blocking- is there a specific address where it is trying to pull this new versions? Is it just https://registry-1.docker.io/v2/?
Edit:
I tried pinging from within my working HA terminal. Can reach 8.8.8.8 and 1.1.1.1 successfully. I tried pinging https://registry-1.docker.io/v2/ , which resulted in:
~ $ ping https://registry-1.docker.io/v2/
ping: bad port spec 'https://registry-1.docker.io/v2/
Then I tried nslookup:
~ $ nslookup https://registry-1.docker.io/v2/
Server: 127.0.0.11
Address: 127.0.0.11#53
notice in the Address how there is a “#” before the port 53. Is that the issue? I am learning this as I go and far beyond my comfort zone, but wouldn’t that normally be a colon (127.0.0.11:53)?
It seems that while I can ping the address, there is a bad port spec. Could it be that while my router can reach through any port, incoming traffic from port 53 might not be allowed? In that case, would the solution just be to add it to port forwarding?
You can’t ping a url. Try pinging the host.
Are you running into github rate limiting?
I’m not sure. how would I know that?
First of all you have two different problems.
- The original one where you cannot get the cli running. Post a comment to the issue what I linked about that. Angers might can point you to the right direction what can cause that.
- You have the problem of updating to 6.1 from 4.15. It is different from the first one (probably). As you described you are seeing a blank screen only after reboot. This is what you need to open a ticket about.
If I would be you, I would start from scratch, burn a new image with 6.1 and try to boot it, and if it fails to boot and get HA running, then I would collect all the logs what I can and needed for a bug report and I would open an issue.
If by just installing 6.1 from scratch you can see the same issue as the original one, then I would just put my RPi into my pocket and I would visit a friend who has different ISP and router and I would try to update there. Not a fancy and techie solution but can solve your issue. (The person in the aforementioned issue solved the problem by using a VPN, what is kinda using a different ISP. A VPN would give you a different public IP, what can be useful if @nickrout is right and you are hitting a github or docker rate limit. But I am just guessing.)
Regarding the ISP blocking something. If you have never seen any website blocked by your ISP, then it is probably safe to say, that your ISP is not blocking it.
If something is blocked by the ISP, you would see a website instead the one you wanted to visit, which would tell you that it has been blocked for X or Y reason.
Thank you. I will post in that link you provided and open a ticket.
I have already tried (many times) to start from scratch with 6.1, with the same issue. I do have a neighbor with a different ISP who I can probably use, but won’t see them till Tuesday. So if I don’t get things worked out over the weekend, I will try that route.
Will follow up here with any results.
Upon searching the bugs, it seems that someone has already described the issue here perfectly, and it is affecting many other pi 3B+ users.
Not sure what’s causing it, but something changed and caused this issue after 4.15/4.16.
1 Like
So I appear to be having the same issues, however I’m trying to create a VM on a Proxmox server, following the example in the link below. I’ve followed the same diagnostics as ezankel and had identical results, so whatever is causing it, I’m not sure it’s RPi related.
1 Like
Exactly Same for me trying a new install on raps pi4 8gb
I actually am running into this myself. So it’s not an isolated problem
1 Like
So I managed to get it working. I had to get into the command line and use nmcli to change my DNS using
nmcli con mod <connectionName> ipv4.dns "8.8.8.8 8.8.4.4"
then ignore the auto DNS using:
nmcli con mod <connectionName> ipv4.ignore-auto-dns yes
Where your connection name is whatever pops up when you do a nmcli con.
4 Likes
Update: Workaround!!
@ewkinder, I was about to come on and report that I had success as well after changing the ipv4 dns for the default wired connection. Mine now works after changing the DNS to 1.1.1.1, even on Wifi.
@raidnet-ms wait until your system errors and looks like this:
Waiting for the Home Assistant CLI to be ready...
[WARN] Home Assistant CLI not starting! Jump into emergency console…
#
Then I would follow what @ewkinder did.
If you’re not sure about your connection name, look at my directions below for the commands.
My method:
I took a different route to accomplish the same system changes and accomplished the same result:
First, find out what your connection name is, so that you can change the DNS:
nmcli con show
In my case, the eth0 default connection name is “Home Assistant OS default”. It is highlighted in green
Then type:
nmcli con edit "Your Connection Name" to enter edit mode for that connection. If your connection has spaces like mine, make sure to put it between the quotation marks.
nmcli> print ipv4 will show you the ipv4 properties of that connection
Set the DNS server and local gateway while you’re here.
nmcli> set ipv4.dns 1.1.1.1
nmcli> save
nmcli> quit
After saving and leaving the nmcli editor, reboot your machine:
# reboot
If this doesn’t work, try activating Wifi and connecting that way first using the instructions here: Guide: Connecting Pi with Home Assistant OS to wifi (or other networking changes)
This seems to be an issue with the way that the default DNS is set up. What I was missing before was that I was not setting the DNS specifically for the connection, but the system as a whole. Once forcing it to use google or cloudflare dns, everything booted up perfectly after a restart. I haven’t had time to submit the bug yet, but I’m convinced that some time after 4.15, the default network settings changed, and for whatever reason they don’t work as well for Pi3B+.
7 Likes