HA Green install stuck during preparation step

Hello, I need some troubleshooting help. I had a HA Yellow for a couple years working fine, but needed to replace it. I have a new HA Green which I’m trying to setup but it gets stuck during the “Preparing Home Assistant” step, with the following errors every 30sec in the log:

2025-06-26 12:46:00.651 INFO (MainThread) [supervisor.updater] No Supervisor connectivity, delaying version fetch

2025-06-26 12:46:00.651 WARNING (MainThread) [supervisor.homeassistant.core] Error on Home Assistant installation. Retrying in 30sec

I have the Green box connected via ethernet directly to the router (not thru a switch). I can access internet from all other applications, and my previous HA Yellow never had any issue on the network.

Note that the time/date in the above errors is my first clue as it is from 2025. I’ve checked what I can find in the router regarding SNTP, and as far as I can tell it is correctly synchronizing the time as when I check the clock setting in the router it has the correct time/date.

Other troubleshooting I’ve checked:

  1. I can connect from a browser to github.com, ghcr.io, and version.home-assistant.io.
  2. I can NOT connect to registry.home-assistant.io. I found some troubleshooting articles that mentioned this is needed, but I cannot connect to it via browser. But I also tried connecting from my phone without wifi and just using mobile connection (to bypass my router) and I can’t connect then either. Not sure if this is a problem or not.
  3. For DNS, I have the attached screenshot of the settings

Does anyone have any ideas or next steps I can try to better troubleshoot or resolve this so the install can proceed?

Thanks,

Gary

Your router might have the correct time but the Green does not. This can prevent SSL certificates from being validated.

Though NTP is not a secure protocol and the green should be able to reach an Internet NTP service to set the time. :man_shrugging:

If you have access to the CLI you can set the time manually.

ha> login
#> date -s "YYYY-MM-DD HH:MM:SS"

This will not persist across reboots unless you have the optional CR2032 coin cell battery installed in the Green.

Thanks for the quick response. Is there a way to connect to CLI remotely or do I need to use physical keyboard/monitor connected to Green?

How are you viewing the logs?

I’m just connecting via browser from my Windows laptop to homeassistant.local:8123

It has been more than a while since I did an install and I did not realise you could see the logs from here:

So yes you will need to attach a monitor and keyboard.

Just wanted to follow up with what seemed to be the solution. I connected monitor/keyboard and tried the command you provided to set date/time. It did set it, but I continued to get the errors during setup preparation (but with correct date/time in the logs).

So next I tried putting in a CR2032 battery, which you mentioned was optional. After installing that and rebooting, the setup completed perfectly.

I’m happy to have it resolved and the HA Green up and running now. But still not sure what the root cause of the problem was. But wanted to post this in case anyone else is searching for a similar issue.

Thanks.

Some have had similar issues doo to not installing Battery, however i had non, and still haven’t installed a battery
So it could be that your are using an Internal DDNS , for some reason ? , so HA during the “Setup” couldn’t contact any NTP server

1 Like

Easiest solution would be to bundle in the button battery with each and every Green, and this would save the problem resurfacing here and being resolved, week in, week out. Like Pavlovs dog, seeing the word ‘green’ mentioned in these forums now always triggers the association of ‘battery’. It points to a design logic oversight in the installation flow, that should have been remedied long ago.

Alternatively, why not a installation screen, asking to confirm time and date if it detects it is epoch time, or at least a more meaningful entry in the system log, and a screen display saying ‘Fetching the current time over the internet. If this screen persists, check your network for errors’ flash past as it attempts to fetch the time?

Alternatively, pre-set the time and date premptively to the time the OS Core release was packaged if it detects it is not valid, so a NTP failure at the early stages is not an issue?

I totally agree, both hardware/software vice, the reason i didn’t install any battery was however Not that there was none in the “packet” (i always have dozens at home) , reason was
“Why the hell should i start my brand new Device with opening it/tearing it all apart !”, just to plug in a battery.
Also, Here it basically means " End of Guaranty " if you open such Hardware ( as there’s no specific for inserting a battery, you are tearing the box apart ! )

And howto software vice, initially ignore the (obvious) time discrepancy, seems as You mention as a “hick-up” , However as lots of Networks Setups is far from the same, the risk is that any/most initially requests to other than a NTP, will be rejected, do to the time-discrepancy.

Most people have little to no knowledge in regards to NTP but in specific DNS( And DHCP for that matter ), and for many years internet have been overflowed with contra “productive” DNS recommendations, using/setting Google etc etc. as “default” in Routers and Devices. Which many “home” tinkers sometimes “follows”, along with other “homemade” devices specific setting etc.

Fact is Any decent Router(default settings) And decent IP provider manage this(often better than most ordinary people), as the Provider has a Customer responsibility, And they know how their own Network is setup to provide Fast and “Best” NTP/DNS Service.
Average people should just point their internal DNS/NTP to the local Routers IP i.e(192.168.x.1) , actually that’s how most Routers Default DHCP-Setting is configured ( Meaning Don’t Do anything, let Your Router and Provider manage these “services”, just send Your IP “packages” )