i think that the problem isn’t linked with debian, but some other issue!
i’ve update supervisor and core to the last versione but the issue persist…
sorry, I didn’t see you reply!
Did you get to solve?
The time/date issue is the same we have with broken hassio!
But moving to Debian my issue is solved. In your case seems still there.
Your router has correct time/date config?
Same issue. Brand new PI, SD card and image. Was able to update from core-2021.4.4 to core-2021.4.6. Add-on showed up for a bit and then gone. Tried all suggestions above to bring them back, no luck.
Preformatted text`21-04-21 16:59:58 ERROR (MainThread) [supervisor.store.git] Can't update https://github.com/home-assistant/addons repo: Cmd('git') failed due to: exit code(128)
cmdline: git fetch --depth=1 --update-shallow -v origin
stderr: 'fatal: unable to access 'https://github.com/home-assistant/addons/': Could not resolve host: github.com'.
21-04-21 16:59:58 INFO (MainThread) [supervisor.resolution.module] Create new issue IssueType.CORRUPT_REPOSITORY - ContextType.STORE / core
21-04-21 16:59:58 INFO (MainThread) [supervisor.resolution.module] Create new suggestion SuggestionType.EXECUTE_RESET - ContextType.STORE / core
21-04-21 16:59:58 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-744' coro=<Repository.update() done, defined at /usr/src/supervisor/supervisor/store/repository.py:105> exception=StoreGitError()>
Traceback (most recent call last):
Hey ilceko!
I did, no more than 48h ago… But i had to go quite a different path to sort my problem out, as with Debian i wasn’t gogin any were…
As mentioned the problem was for sure within the System clock synchronized status NTP service status… that they were displayed all the time as follows:
$ timedatectl
Local time: jue 2021-04-22 23:04:21 CEST
Universal time: jue 2021-04-22 21:04:21 UTC
RTC time: n/a
Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
And as simple as it might seem to turn it into “yes”, by using the command:
apt-get install ntp
(i used abunch of other command i don't remmember...)
sudo systemctl start systemd-timesyncd
I never got to make it work
So reading on different forums i found that HA could also be installed on the Raspberry Pi OS, tought not supervised anymore, and there were a set of commands (in this forum: Como configurar la fecha y hora - Raspberry Pi Forums) where the most important was
sudo raspi-config
And from the interactive menu that pops up → Select Boot Options → Wait for Network at Boot → Yes.
Once done that, my System clock synchronized was set to yes! (tought NTP service is inactive… 
nevertheless it seemed to be enough to get the repository back on track.
$ timedatectl
Local time: jue 2021-04-22 23:04:21 CEST
Universal time: jue 2021-04-22 21:04:21 UTC
RTC time: n/a
Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
So to be honest, i feel a bit frustrated because the “amateur” installation version shown in here: Raspberry Pi - Home Assistant should work, but it didn’t for me, not to blame the programmers as they have done an amazing job, just frustrated that as an amateur user i haven’t been able to enjoy of it.
Anyhow, im going to be using the HA on Raspberry Pi OS for as long as it lasts and meanwhile will get an other sd card and keep on trying with debian, so maybe ill learn along the way 
Be in touch guys!
I have the same issue. 
Only seems to have occurred since update to 2021.4.5 yesterday
Tried updating DNS server from command line
Tried full restore to earlier versions
Running on a RPI on Hassio on top of docker (supervisor)
OK - hope this helps someone identify the real root cause of this issue…
In the log file, I noticed some git errors, one of which failed on:
git clone --depth=1 --recursive --shallow-submodules -v GitHub - home-assistant/addons: ➕ Docker add-ons for Home Assistant /data/addons/core
So, amending dns with:
ha dns options --servers dns://1.1.1.1
ha dns restart
did not allow for the command to succeed. So I tried looking up github.com and manually added an entry in the /etc/hosts file.
re-running the failing git commands seemed to work now.
whilst the error now appears to be missing from the supervisor log - still missing repositories.
After a reboot - checking the /etc/hosts file appears to gave removed my edit
(probably some integrity protection stuff)
from the update command it now appears that I have updated content under
/data/addons
Just not sure where to go for here.
The core problem definitely seems to be liked to name resolution for github.com
Any ideas?
Interestingly, after all of this, I cannot add the standard HA repository:
https://github.com/home-assistant/addons
I have also tried adding a new repository using the IP address instead of the hostname - no change 
My current list of add-on repositories (which seems kind-of working):
https://github.com/home-assistant/addons
https://github.com/hassio-addons
https://github.com/hassio-addons/repository
1 Like
Same proplem…
Is anyone doing anything about this issue? Seems like it’s happening to a lot of people.
I have raised the issue on the discord server so will see if one of the devs has a view. Meanwhile i have been trying local DNS and other workarounds.
Finally fixed the problem. Was an Amazon eero with latest update that seemed to have been causing all of the carnage.
After doing all of the above and relocating directly to an alternate Internet route - all working and demons purged.!!
Good Luck guys!
1 Like
Thanks, got it working
1 Like
Can you provide any additional information here? Been struggling with this for months on one of my two on-site homeassistant instances – both on the same network, both behind an eero system, one works and the other doesn’t…
Same problem here
ERROR (MainThread) [supervisor.store.repository] Can't remove built-in repositories!
So the problem seems to have been caused by one of the eero updates and some caching of bad DNS records.
I fixed the problem by shutting down then relocating ha to connect directly to the Internet (in front of the eero). I then started it up, waited 15mins (for it to refresh everything) then turned it off (as i could not easily access the newly allocated DHCP address from my border router)
After putting it back where it was and powering up again - all sorted.
1 Like
I also found this which allows for editing HA OS networking config. which was helpful in debugging.
1 Like
The problem went away for a while then came back.
Lead me to this page:
https://adam.younglogic.com/2019/05/using-nmcli-to-set-nameservers/
The key sections were (where “System eth0” is the network name) :
nmcli conn modify “System eth0” ipv4.ignore-auto-dns yes
nmcli conn modify “System eth0” ipv4.dns “192.168.24.7 8.8.8.8”
systemctl restart NetworkManager
Clearly some behaviour has changed in HA that is in conflict with the way eero is issuing DNS updates
Sadly (after having all of this working) it has now reverted to its previous broken state.
[very frustrated - perhaps one of the devs can offer another suggestion]
Symptoms are still the same - i.e. the HA box cannot resolve GitHub.com
[update] I have just asked the eero folks whether i can downgrade to the previous eero version - this is driving me nuts.
[update] So from the command line I have noticed that the resolution seems to be happening at the docker level. Adding new name servers into /etc/resolv.conf does not appear to help. Does someone know how to update DNS inside docker?
There is a “Local DNS caching” option in the Eero configuration. HAs anyone tried disabling that?
UPDATE: I tried that, and no changes…
I was experiencing this issue on a new install. In the HA command prompt “info” would return an issue with the date/time. It was resolved with the recommendations above. I had to reboot to Raspi OS. There I changed the boot order to wait for network in the GUI. I checked that the time and local were accurate. In the command prompt I activated NPT as described here:
Hope this helps!