Core Update 2026.5.0 to 2026.5.1 Fails to Load Image

Installation
1

History...
Started with the Core 2026.5.0 to 2026.5.1 update. GUI update fails just at the start of the % install. Tried several things with assistance of forums and AI but did not resolve. Then Supervisor 2026.5.0 update was released and Core stated must install Supervisor first. Supervisor update 2026.5.0 failed similar to Core and again with assistance still was unable to get Supervisor to update. Worked with user on Discord and was able to get Supervisor to update to 2026.5.0. The step that made the update succeed was to reset HA Green and then load a backup that I made previous to the reset. Supervisor updated to 2026.05.0 and HA was up and running; however, Core still will not update. Here are some of the things that were tried:
Set DNS on HA Green to 1.1.1.1 & 8.8.8.8
Disabled ipv6
Added vpn to router and set HA to use vpn (OpenVPN)

Supervisor Log:

2026-05-16 13:42:10.754 WARNING (MainThread) [supervisor.docker.manifest] Failed to get token from https://ghcr.io/token: 403
2026-05-16 13:42:10.821 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/home-assistant/green-homeassistant:2026.5.1 - 401
2026-05-16 13:42:10.821 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/green-homeassistant with tag 2026.5.1.
2026-05-16 13:42:11.505 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/green-homeassistant:2026.5.1: [403] error from registry: denied
2026-05-16 13:42:11.506 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed

Yesterday, I tried to capture the steps and output in order as I tried to solve Core Update:

here is the ping and nslookup 
➜ ~ ping ghcr.io PING ghcr.io (140.82.113.33): 56 data bytes 64 bytes from 140.82.113.33: seq=0 ttl=38 time=105.068 ms 64 bytes from 140.82.113.33: seq=1 ttl=38 time=122.687 ms 64 bytes from 140.82.113.33: seq=2 ttl=38 time=99.414 ms 64 bytes from 140.82.113.33: seq=3 ttl=38 time=114.298 ms 64 bytes from 140.82.113.33: seq=4 ttl=38 time=110.993 ms 64 bytes from 140.82.113.33: seq=5 ttl=38 time=103.861 ms 64 bytes from 140.82.113.33: seq=6 ttl=38 time=100.913 ms ^C --- ghcr.io ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 99.414/108.176/122.687 ms
➜ ~ nslookup ghcr.io Server: xxx.xx.xx.x Address: xxx.xx.xx.x#53 Name: ghcr.io Address: 140.82.113.33

Your network and DNS look healthy. The host can resolve and reach ghcr.io, so this is probably not a basic connectivity problem.

That narrows it down to:

temporary GitHub Container Registry auth issue
stale/corrupted Docker auth/cache on the host
Supervisor/Docker issue
blocked GitHub token endpoint specifically (less likely now)

The key detail is still:

Failed to get token from https://ghcr.io/token: 403

Ping and DNS do not test that token endpoint.

here is the curl 
➜ ~ curl -I https://ghcr.io/token HTTP/2 405 content-type: application/json docker-distribution-api-version: registry/2.0 strict-transport-security: max-age=63072000; includeSubDomains; preload date: Fri, 15 May 2026 19:35:44 GMT content-length: 78 x-github-request-id: 11D8:3BEA76:2BE9DC:316CEC:6A07758F

means:

HTTPS connectivity works
TLS certificates work
GitHub token endpoint is reachable
your DNS/network path is fine

So the problem is now very likely one of these:

stale/corrupted Supervisor Docker auth state
temporary GHCR anonymous pull rejection
outdated Supervisor/container tooling

here is the ha supervisor info
addons: - icon: true name: ESPHome Device Builder repository: 5c53de3b slug: 5c53de3b_esphome state: started update_available: false version: 2026.4.5 version_latest: 2026.4.5 - icon: true name: Samba share repository: core slug: core_samba state: started update_available: false version: 12.6.1 version_latest: 12.6.1 - icon: true name: File editor repository: core slug: core_configurator state: started update_available: false version: 6.0.0 version_latest: 6.0.0 - icon: true name: Advanced SSH & Web Terminal repository: a0d7b954 slug: a0d7b954_ssh state: started update_available: false version: 23.0.9 version_latest: 23.0.9 - icon: true name: eufy-security-ws repository: 402f1039 slug: 402f1039_eufy_security_ws state: started update_available: false version: 2.1.0 version_latest: 2.1.0 addons_repositories: - name: Local apps slug: local - name: ESPHome slug: 5c53de3b - name: Home Assistant Community Store slug: cb646a50 - name: Music Assistant slug: d5369777 - name: 'Home Assistant Add-on: eufy-security-ws' slug: 402f1039 - name: Official apps slug: core - name: Home Assistant Community Apps slug: a0d7b954 arch: aarch64 auto_update: true channel: stable country: US debug: false debug_block: false detect_blocking_io: false diagnostics: null feature_flags: supervisor_v2_api: false unix_socket_core_api: false healthy: true ip_address: xxx.xx.xx.x logging: info supported: true timezone: America/New_York update_available: false version: 2026.05.0 version_latest: 2026.05.0 wait_boot: 5

Your Supervisor looks healthy and current:

Supervisor: 2026.05.0
Channel: stable
Architecture: aarch64
Healthy: true

Very likely cause now: GHCR anonymous pull rejection

Because:

DNS works
HTTPS works
Supervisor is current
system is healthy

…the registry is probably rejecting the anonymous image token intermittently.

That exact pattern:

403 token
401 manifest
denied

usually means:

auth token request failed upstream
not local corruption

This has happened periodically with GitHub Container Registry and Home Assistant image pulls.

What I suspect most right now

Given everything you've shown, the probability order is roughly:

transient GHCR authentication rejection
stale container/image metadata fixed by rebuild
low storage
Docker layer corruption

Not:

DNS
internet connectivity
Supervisor version
Home Assistant configuration

The best next step is:

ha core rebuild
ha host reboot
retry update

Then, if it still fails, paste:

ha info
df -h
result of docker pull (or the error saying Docker unavailable)
newest Supervisor log after retry

ha info 
➜ ~ ha info arch: aarch64 channel: stable docker: 29.3.1 features: - reboot - shutdown - services - network - hostname - timedate - os_agent - haos - resolved - journal - disk - mount hassos: "17.3" homeassistant: 2026.5.0 hostname: homeassistant logging: info machine: green machine_id: 61de988d8aea4288b17fca0c327363c3 operating_system: Home Assistant OS 17.3 state: running supervisor: 2026.05.0 supported: true supported_arch: - aarch64 timezone: America/New_York

Everything looks current and healthy:

Home Assistant OS 17.3
Home Assistant Core 2026.5.0
Docker 29.3.1
Supervisor 2026.05.0

So your system stack is not outdated.

At this point, this is almost certainly one of:

temporary GHCR registry auth failure
stale image/cache metadata
low disk space

The remaining high-value check is storage.

Run:

df -h

here is storage
Filesystem Size Used Available Use% Mounted on overlay 27.8G 8.3G 18.1G 31% / /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /data /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /ssl /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /addon_configs /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /addons /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /homeassistant /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /backup devtmpfs 1.7G 0 1.7G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /share /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /media tmpfs 784.6M 1.7M 782.9M 0% /run/docker.sock tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /run/audio /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /run/cid tmpfs 784.6M 1.7M 782.9M 0% /run/dbus /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /etc/asound.conf /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /etc/resolv.conf /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /etc/hostname /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /etc/hosts tmpfs 784.6M 1.7M 782.9M 0% /run/log/journal /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /var/log/journal /dev/mmcblk0p8 27.8G 8.3G 18.1G 31% /etc/pulse/client.conf tmpfs 1.9G 0 1.9G 0% /proc/asound devtmpfs 1.7G 0 1.7G 0% /proc/interrupts devtmpfs 1.7G 0 1.7G 0% /proc/keys tmpfs 1.9G 0 1.9G 0% /proc/scsi devtmpfs 1.7G 0 1.7G 0% /proc/timer_list tmpfs 1.9G 0 1.9G 0% /sys/firmware

At this point your system checks all look healthy:

network/DNS works
HTTPS to GHCR works
Supervisor current
OS current
Docker current
plenty of storage
Home Assistant healthy

That leaves two very likely possibilities:

stale Docker/Supervisor image state
temporary GitHub Container Registry authorization issue

So now the most appropriate fix is operational cleanup rather than troubleshooting basics.

ha core rebuild

ha host reboot

After the system comes fully back online, retry the update.

Update failed 

docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.1

➜  ~ docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.1
2026.5.1: Pulling from home-assistant/green-homeassistant
1bdaaf0c09b0: Pull complete 
c537d70fa6d1: Pull complete 
8ea8deadfdc7: Pull complete 
bf2874ea635c: Pull complete 
fa911897150b: Pull complete 
6f1dec89aca4: Pull complete 
8603c9a9ee92: Pull complete 
3822f3964169: Pull complete 
b0143cbb2b04: Pull complete 
9904c79f9310: Download complete 
Digest: sha256:31efa3db018133934737efeb0ce717c78aca201a91b0b620344f60b6e1242353
Status: Downloaded newer image for ghcr.io/home-assistant/green-homeassistant:2026.5.1
ghcr.io/home-assistant/green-homeassistant:2026.5.1


Pull succeeds

Then the registry is fine and Supervisor had stale metadata/auth state.

Retry:

ha core update --version 2026.5.1

➜  ~ ha core update --version 2026.5.1
Processing... Done.

Command completed successfully.

ha info
➜  ~ ha info
arch: aarch64
channel: stable
docker: 29.3.1
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
- haos
- resolved
- journal
- disk
- mount
hassos: "17.3"
homeassistant: 2026.5.0
hostname: homeassistant
logging: info
machine: green
machine_id: xxxxxxxxxxxxxxxxxxxxxxxxxx
operating_system: Home Assistant OS 17.3
state: running
supervisor: 2026.05.0
supported: true
supported_arch:
- aarch64
timezone: America/New_York

ha core info

➜  ~ ha core info
arch: aarch64
audio_input: null
audio_output: null
backups_exclude_database: false
boot: true
duplicate_log_file: false
image: ghcr.io/home-assistant/green-homeassistant
ip_address: xxx.xx.xx.x
machine: green
port: 8123
ssl: false
update_available: true
version: 2026.5.0
version_latest: 2026.5.1
watchdog: true

powered off both internet modem/gateway and router, after ~30 seconds powered the modem/gateway back on and waited until it was up then powered router back on wand waited until it was up then ran 

➜ ~ docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.1 2026.5.1: Pulling from home-assistant/green-homeassistant bf2874ea635c: Pull complete b0143cbb2b04: Pull complete c537d70fa6d1: Pull complete 1bdaaf0c09b0: Pull complete fa911897150b: Pull complete 6f1dec89aca4: Pull complete 3822f3964169: Pull complete 8603c9a9ee92: Pull complete 8ea8deadfdc7: Pull complete 9904c79f9310: Download complete Digest: sha256:31efa3db018133934737efeb0ce717c78aca201a91b0b620344f60b6e1242353 Status: Downloaded newer image for ghcr.io/home-assistant/green-homeassistant:2026.5.1 ghcr.io/home-assistant/green-homeassistant:2026.5.1

That result is the confirmation we needed:

Status: Downloaded newer image for ghcr.io/home-assistant/green-homeassistant:2026.5.1

So:

GHCR access is working again
your network path is clean
the previous 403/401 failures were transient registry/network authentication issues tied to your WAN path or IP session

The modem/router power cycle effectively cleared whatever was causing GitHub’s registry edge to reject the token request.

What to do now

Run the Home Assistant update again (it should succeed immediately now):

ha core update --version 2026.5.1

Then verify:

ha info

You should see:

homeassistant: 2026.5.1
What actually happened (in plain terms)

Your Home Assistant Supervisor was fine the entire time.

The failure was here:

GHCR token endpoint returning 403 for Docker requests only
curl worked because it hit a slightly different request path
Docker/Supervisor used a different auth flow that was being rejected

After the network restart:

your WAN IP / routing path likely changed
GHCR stopped rejecting the token request
Docker pull succeeded normally
Why this is a known pattern

This specific combo:

ghcr.io/token 403
manifest 401
manual curl works
fixed by router/modem reboot

…almost always points to:

transient IP reputation / edge routing issue on GitHub’s side
or ISP NAT behavior reset

Not a Home Assistant bug.

Bottom line

You’re unblocked now. Just rerun the update and it should complete normally.

If it somehow fails again, paste the new log—but based on your successful docker pull, this is essentially resolved.

ha info

➜  ~ ha info
arch: aarch64
channel: stable
docker: 29.3.1
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
- haos
- resolved
- journal
- disk
- mount
hassos: "17.3"
homeassistant: 2026.5.0
hostname: homeassistant
logging: info
machine: green
machine_id: 61de988d8aea4288b17fca0c327363c3
operating_system: Home Assistant OS 17.3
state: running
supervisor: 2026.05.0
supported: true
supported_arch:
- aarch64
timezone: America/New_York

➜  ~ ha core update --version 2026.5.1
Processing... Done.

Command completed successfully.
➜  ~ ha info
arch: aarch64
channel: stable
docker: 29.3.1
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
- haos
- resolved
- journal
- disk
- mount
hassos: "17.3"
homeassistant: 2026.5.0
hostname: homeassistant
logging: info
machine: green
machine_id: 61de988d8aea4288b17fca0c327363c3
operating_system: Home Assistant OS 17.3
state: running
supervisor: 2026.05.0
supported: true
supported_arch:
- aarch64
timezone: America/New_York

This is the same situation as before: the update command succeeded, but the Core container is still running the old version.

So right now:

Supervisor thinks update ran
Docker image is already downloaded (you confirmed that)
But Home Assistant Core did not restart into the new container

I felt I was in a loop much like before on the Supervisor Update and stopped.

Any suggestions or assistance is greatly appreciated and thanks in advance!

2

I would start looking there. HA likes flat networks, and if you don't have all the right protocols passed thru the VPN, talking to the outside sometimes fails, IE things won't update.
Also if you have a DNS re-director installed, that can also be a cause. (PiHole, AdGuard, etc)

1 Like
3

Thanks for the response.
I do not have a DNS Redirector. That was suggested in conjunction with the Supervisor update issue.
Previous updates to Core 2026.5.1 loaded without issue.
I believe Core 2026.5.0 was released about 1-2 weeks ago and it installed no issue and I have not changed anything like ISP, Router or Gateway and the VPN was added as a test to get Supervisor Update to load. I do not believe the VPN solved anything previously as it was the HA Green reset that made the Supervisor update. The person helping me who suggested the VPN for the Supervisor update had me remove it in an attempt to get the Core update to run. To add a different VPN would require $$$.
I have a T-Mobile Home Internet Gateway with a TP-Link Archer AX21 Router.
HA Green has been running over a year and has been very stable. This is my first 'difficult' issue with updates.

The Supervisor log that I attached was run without VPN and with DNS at 1.1.1.1 and 8.8.8.8. Note, before this all-started, HA Green DNS pointed to the router but I added Cloudflare & Google.

I am at the end of my rope and all out of things to try.

4

Moved HA Green to a port on the router then moved it to a port on the T-Mobile Gateway. Again, Core update 2026.5.2 failed to load and system came up on Core 2026.5.0 on each attempt.

5

Why did you made that change ? , And was it after this change it all started ?

In Most common solutions the best way is to let your Router pass on requests to your ISP ( Most ISP's has a comprehensive cache , and have the best knowledge in regards to provide DNS services for their own Customers )

Many People which "Plays with DNS" have no idea what they are doing, nor whether it's actual is a benefit in their particular situation, they follow "Mainstream suggestions provided/promoted by and from Google and Cloudflare " ... Harsh Reality

Note: You don't have DNS issues, neither when you posted your problems in the Release-Topic
I connects fine to Github

PS: Try to disable all your add-ons (Apps) run update core, from the cli
And Get use to update from one and same Device, And as i mentioned before, Not From a Mobile

If you just Reseted to fresh HA, to get Supervisor installed, then you should have Updated Core, BEFORE You updated this with Your Backup ( Could be so that the root cause is in that particular Install/Configuration ) Consider your AI assistant and everything else you have installed with the help of Your AI

6

Thank you for the response.

I added 1.1.1.1 and 8.8.8.8 per a suggestion on a forum.

I also work with someone on Discord who suggested the reset which is when Supervisor did update. It was not suggested to perform any updates after the reset and prior to doing the backup restore. I suspect but not sure that it was expected that both updates would have occurred.

Can you provide the steps that I should take to try and resolve this issue?

I can run commands in SSH/Terminal but I will need some guidance as to what those commands are and what response I should be looking for.

For example, the person on Discord sent me a couple of links and one had the step by step to reset HA Green.

I am an old hardware guy but have been around a lot of software and given some guidance I can typically get things to run.

thank you in advance for any assistance.

7

I just looked at Apps and can I just stop the Apps and would that be enough to 'disable' them or should I delete them?

Also, could you provide the commands in CLI to do the update?

I have run some many commands at this point that I would like to make sure I run the exact ones that are needed.

8

Sorry I really did not directly answer your question. HA Green has been running for over a year and I have not had any issues until now. It started with Core 2026.5.1 update and then when Supervisor 2026.05.0 was released it continued and was told I needed to update Supervisor before Core. All changes I made were in support of trying to get Core to update and then Supervisor. As noted, I was successful in getting Supervisor to update (with the assistance of someone on Discord) by reset of HA Green but Core still fails. Now Core 2026.5.2 is released but it still fails to update. I was concerned with restoring a backup that was recent as I could be putting something 'broke' back onto the box. I make backups every Monday to a WIn11 PC so I should have a backup from prior to the start of this issue.

I believe I have reversed all of the network, DNS, VPN attempts and I am now back to the settings prior to the start of this issue except for one which is I have ipv6 disabled.

I have been doing all work from a browser (Chrome) session on Win11 using the GUI and the App SSH/Terminal.

I believe you suggested to disable the Apps and then run CLI commands. Not sure of some of the terminology but I think you are suggesting I run commands (CLI) but that would require SSH/Terminal but if I would disable all Apps I would not have SSH/Terminal. Please clarify. Is it ok to stop all of the Apps and then retry the Core update from the GUI?

Thank you again for the response and any assistance.

9

What router make and model are you using? How is your Green connected to it - wired or wireless?

Any reason why IPv6 settings have been touched?

How many VPNs are you running?

Any network appliances such as PiHole, bridges, repeaters, switches and added routers connected?

Does having a browse in Settings / system / network/ and all three options in network discovery yield any useful hints?

How about System / repairs / system information (click the three dots on the right to access)

Have you tried logging out and back in to GitHub?

Are your docker token errors consistent as well as persistent? What breaks intermittently, and what breaks consistently? What version of Docker are you running?

What apps are you running on your Green? HACS as well as inbuilt please.

Any chance of a copy of the CLI welcome screen contents? Any errors mentioned there?

Comment: your systematic research is too summarised and focused (Do I smell AI having a role here), not quoting actual full logs, hence the seemingly unrelated hints and clues often picked up to help isolate the problem (based on human troubleshooting experience) are missing or have been overlooked.

10

Yes i did, maybe not the best step-by-step suggestion i gave You , But First i mend if You managed to Reset the Homeassistant Green and i Came Up again with 2026.5.1, and Updated Supervisor to 2026.5.0 then everything looked to works as intended

I Recall you "Previous" Status

Sorry i do get confused by your repeated Commends ( And your posting your AI’s troubleshooting it seems ), and it seems like You don’t remember what your told/said in the Release-blog 7 days ago. Wheels keep spinning.
If when you post your AI “Findings” make sure to clearly State So !, that it comes from Your AI !!!

Most of all, if you keep using your AI ( They way you Does ) Make Sure To Note/Secure the the Source( Summaries ) Your AI present, in fact Not Comes from Sources, Like The posts you done here , in the Relese-Block or Discord
I Assume you are aware that AI, is Just A Summary, depending upon which AI, it could infact just summarize your own Topics/Posts

Common basic trouble-shooting could be the best way forward

  1. You didn’t experienced these issues, prior to try to update to core 2026.5.1
    What Changes in your Environment Network/Hardware/Software has been made since updating to 2026.5.0 ? … Did You carefully read the Release note of 2026.5.0 ?, so you verified/secured that there wasn’t changes which you had to pay attention to ?
    Etc.
    For an “outstander” it’s impossible to know what you’ve done and when etc. etc. and which setting/integrations/Apps you made changes to and/or needed updates/changes.
    And if you ( so deeply as you make it sound ) try to “Learn” from AI , It could take time and lots of confusing to You.

CLI: When People using that terminology they usually means you connect Direct to the HA-Host , NOT through SSH ( Where you log into a Shell with a given user/credentials which might differ from HA ) Hint: the reason you have to use “ha” in front of shell-commands to tell your SSH Shell to run a a HA Command
In HA’s CLI ( accessed direct on it’s Hardware ) , You can Not run Common shell commands !
Connecting a Monitor to your Greens HDMI and a keyboard to it's usb-port, You will access and can work Direct on Your HA- Machine, through it's CLI,

However now you already have applied your backup, which could contain configurations/etc which causes your Install this behavior.

If you try to restart your HA in Safe-Mode, Then All Add-ons(Apps) and integrations will not be loaded (Disabled)

General troubleshooting - Home Assistant .

After starting HA in Safe-Mode you could try to Run core update version
Common tasks - Home Assistant Operating System - Home Assistant .

NOTE: i know by now You are a fan of AI, You also said that in the 2026.5 Release Blog
However i suggest You try to get familiar with HA’s Documentations

If You succeed to update core this(above) way it’s obvious that the root-cause is in your Old-Install ( As You also can reset HA ) and get latest Version, Which seemed to be the Way you got to core-2026.5.0 , Dump You old backup in Windows Bin, After you copied you yalm’s txt-files etc ( If you can’t trouble-shoot it )
However it could be caused by your old backup anyhow, noone but you can find out.

PS: i also suggest you enable IPv6 again in HA, But !, disable it in Your Router/gateway ! , as i doubt you have reasons to involve your Router for this. ( im not aware of your Hardware setup T-Mobile Gateway + Router ) Sounds like you need to also read up upon it’s Software.
Also i assume you have “default” settings in HA in common (As IOT7712 suggested above, system information/settings will bring a light to this)
However do you have a “reserved” IP for Your HA in your Router ? , if not make sure you have

PS: I have no experience of Resetting My Green, as it has worked flawless, since i got it in Now/Dec. 2025
I don’t have any Battery in it ( And have not experienced any NTP related issues ) , and i a have defaults in Most i.e Network settings ( ipv6 is enabled in HA, as i use Matter Integration/App )
DNS is in my opinion/usecase not a HA task, Any Public IP’s request is to my Lan-Port on my Router, which Uses ISP Provided Settings( Beside i disabled IPv6 there ), Why bother, or use resource on a Service which any decent ISP Provides for free

11

And you changed DNS etc. etc.

Do you know what happens in your Network and in HA when you “play around” like this ?
I have no experience of your T-Mobile “ Gateway “, or your Router for that matter, nor their settings/cache etc.
But i do know that you make a mess by this approach , so log out from every device , And wiping all caches(on all devices, even your Mobile App and Google Play) and shutting down everything ( ALL Device ) and sleep on it, then start on a fresh in a structured manner might be a good way forward.

12

SmileyRG: I have worked with both people via different forums as well as with AI (ChatGPT). I first checked the forums but did not see others with the same/similar issue. I also opened cases in hopes that someone would have suggestions or like me, have the same/similar issue. After some time and no traction with the forums I turned to AI to see if it could resolve. I am not a fan of AI but simply using as a troubleshooting tool. I did notice though that AI would get into a loop and try the same steps over and over. The most traction I got was from a discord user who offered the steps to reset HA Green and that was when Supervisor updated, but I feel he also expected Core to update and is now out of suggestions.

13

In another forum it was suggested to make sure I was logged out of GitHub. I logged out of Git Hub and tried Core 2026.5.2 Update. Failed. The Supervisor log is always the same.

type or p2026-05-18 12:12:51.424 INFO (MainThread) [supervisor.homeassistant.core] Updating Home Assistant to version 2026.5.2
2026-05-18 12:12:51.425 INFO (MainThread) [supervisor.docker.interface] Updating image ghcr.io/home-assistant/green-homeassistant:2026.5.0 to ghcr.io/home-assistant/green-homeassistant:2026.5.2
2026-05-18 12:12:51.889 WARNING (MainThread) [supervisor.docker.manifest] Failed to get token from https://ghcr.io/token: 403
2026-05-18 12:12:51.959 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/home-assistant/green-homeassistant:2026.5.2 - 401
2026-05-18 12:12:51.960 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/green-homeassistant with tag 2026.5.2.
2026-05-18 12:12:52.540 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/green-homeassistant:2026.5.2: [403] error from registry: denied
2026-05-18 12:12:52.541 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed
14

Do you ever look in the CORE RAW log? , have You tried to enable DEBUG when you run the Update command in the CLI, or through GUI ? … Sorry for asking these basic questions, it’s just it feels like you don’t have a structured approach in your various “Attempts” , And as it’s repeated same logs in Supervisor,You need to Change your ways, and maybe start allover again, as suggested
Start over means Wipe ALL Caches “Everything” Everywhere, shutdown your Devices, start-up with only your Gateway Router and HA, connect to to the CLI on HA Devices
Then Run the Reset HA procedure again this time through the CLI, when it’s done You’ll see your New “status” CORE-Version etc, if you are Lucky then it’s uptodate, Then Don’t install/update with your Backup, start on a fresh.

Even here You don’t have to ask AI
https://support.nabucasa.com/hc/en-us/articles/25161225495837-Resetting-Home-Assistant-Green .

Just the ability to follow a step-by-step description, in a structured manner, and understanding of how a Network work/caches etc works

15

@IOT7712

Do you have any other questions or suggestions?

I have gotten a display and keyboard connected to HA Green, but the intro screen looks the same as SSH/Terminal, and I do not see any error messages.

Any other suggestions....

I did work with another forum user last night but I did have a brief internet issue as a strong thunderstorm rolled thru. Here is the session:

ha supervisor options --channel stable
ha refresh-updates
ha available-updates
ha core info

Can you check these? 
You can also try if we can see more info via debug log levels
ha core update --log-level debug
ha supervisor update --log-level debug
 
In the past users also did a downgrade and then a upgrade but I was trying to avoid having you jump through a bunch of such hoops.
I was kinda hoping someone else would jump in with a solution.
Maybe there's a known issue I'm not aware of for example.
This would update to a specific version
ha core update --log-level debug --version 2026.5.2

System is ready! Use browser or app to configure.
➜  ~ ha supervisor options --channel stable                                
Command completed successfully.

➜  ~ ha refresh-updates                    
Command completed successfully.

message.txt
5 KB

If you check the versions here you are on the latest ones: https://github.com/home-assistant/version/blob/4b64ed71d3aa6eba6efeb004235eabf87a812c46/stable.json 
At least for supervisor. If core really was successful then ha core info should show that to be version: 2026.5.2 now too. 
BobG
OP
 — Yesterday at 7:17 PM
I sent the outputs and it put them into an attachment file message.txt.  Anyways, ha core info states: update_available: true
version: 2026.5.0
version_latest: 2026.5.2

:<
Let's check ha supervisor logs and ha host logs again.
BobG
OP
 — Yesterday at 7:18 PM
Here is ha core update --log-level debug --version 2026.5.2  ➜  ~ ha core update --log-level debug --version 2026.5.2
2026/05/18 19:11:59 DEBUG Adding homedir to searchpath homedir=/root
2026/05/18 19:11:59 INFO No configfile found
2026/05/18 19:11:59 DEBUG Debug flags apiToken=bad46b1d38f2ccabaf0439b1623a104a0709031cd1f1ae143bd7ce63b95477c3e6be81a5827adc0ade0765566dbd1abec54ba242460ba5d6 cfgFile="" endpoint=supervisor logLevel=debug noProgress=false rawJSON=false
2026/05/18 19:11:59 DEBUG core update args=[]
2026/05/18 19:11:59 DEBUG [GenerateURI] base=supervisor section=core command=update
2026/05/18 19:11:59 DEBUG [GenerateURI] Result uri=http://supervisor/core/update url=http://supervisor/core/update url(string)=http://supervisor/core/update
⣾ Processing... 2026/05/18 19:11:59 DEBUG Request body body=map[version:2026.5.2]
⣻ Processing... 2026/05/18 19:12:03 DEBUG Response statuscode=200 status="200 OK" time=4.319794534s received-at=2026-05-18T19:12:03.788-04:00 headers="map[Content-Length:[25] Content-Type:[application/json; charset=utf-8] Date:[Mon, 18 May 2026 23:12:03 GMT] Server:[Python/3.14 aiohttp/3.13.5]]" request="&{Method:POST URL:http://supervisor/core/update Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Accept:[application/json] Authorization:[Bearer bad46b1d38f2ccabaf0439b1623a104a0709031cd1f1ae143bd7ce63b95477c3e6be81a5827adc0ade0765566dbd1abec54ba242460ba5d6] Content-Type:[application/json] User-Agent:[go-resty/2.17.2 (https://github.com/go-resty/resty)]] Body:{Reader:} GetBody:0x21c280 ContentLength:22 TransferEncoding:[] Close:false Host:supervisor Form:map[] PostForm:map[] MultipartForm:<nil> Trailer:map[] RemoteAddr: RequestURI: TLS:<nil> Cancel:<nil> Response:<nil> Pattern: ctx:{emptyCtx:{}} pat:<nil> matches:[] otherValues:map[]}" body="{"result":"ok","data":{}}"
Processing... Done.

Command completed successfully.

BobG
OP
 — Yesterday at 7:25 PM
I probably had a network outage around 6:36 / 18:36.  I received a email that a hub for some devices on HA went offline and my wife is watching TV (streaming via Roku) and it went down.  It is back up again.  As with any internet this can happen but it does not happen often.
should I rerun anything again before I rerun ha supervisor logs and ha host logs again

No.
BobG
OP
 — Yesterday at 7:27 PM
here is ha supervisor logs from 18:42
2026-05-18 18:42:15.917 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disk_lifetime/system
2026-05-18 18:42:15.924 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_ipv6_error/dns_server
2026-05-18 18:42:18.761 INFO (MainThread) [supervisor.resolution.checks.base] Run check for pwned/addon
2026-05-18 18:42:18.762 INFO (MainThread) [supervisor.resolution.checks.base] Run check for free_space/system
2026-05-18 18:42:18.765 INFO (MainThread) [supervisor.resolution.checks.base] Run check for multiple_data_disks/system
2026-05-18 18:42:18.766 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_failed/dns_server

message.txt
8 KB
here is the ha host logs from 18:22
2026-05-18 22:11:38.539 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/sbc_xq_512
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSink/sbc_xq_552
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/sbc_xq_552
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSink/faststream
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/faststream
2026-05-18 22:11:38.554 homeassistant bluetoothd[474]: Destroy Adv Monitor Manager

message.txt
8 KB
Does that work or do you need something else.

That's fine.
The no supervisor internet connection is peculiar. What does ha network info say?
BobG
OP
 — Yesterday at 7:37 PM
Here it is:  
➜  ~ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
connected: true
enabled: true
interface: end0
ipv4:
  address:
192.168.0.12/24
gateway: 192.168.0.1
method: auto
nameservers:
192.168.0.1
ready: true
route_metric: null
ipv6:
  addr_gen_mode: default
  address:
fe80::9be5:893a:27ab:294e/64
gateway: null
ip6_privacy: default
method: disabled
nameservers: []
ready: true
route_metric: null
llmnr: default
mac: 20:F8:3B:01:1A:4A
mdns: default
primary: true
type: ethernet
vlan: null
wifi: null
supervisor_internet: false


This is not good
supervisor_internet: false
Check
ha dns info
ha dns logs
BobG
OP


You can also try this
ha network update end0 --ipv4-nameserver 8.8.8.8
ha dns options --servers dns://8.8.8.8 --fallback=false
ha dns restart

and see if that changes. HA does something similar like this to see if you have internet connectivity so try this before and after
curl http://checkonline.home-assistant.io/online.txt

BobG
OP
 — Yesterday at 7:41 PM
➜  ~ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: end0
  ipv4:
    address:
    - 192.168.0.12/24
    gateway: 192.168.0.1
    method: auto
    nameservers:
    - 192.168.0.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - fe80::9be5:893a:27ab:294e/64
    gateway: null
    ip6_privacy: default
    method: disabled
    nameservers: []
    ready: true
    route_metric: null
  llmnr: default
  mac: 20:F8:3B:01:1A:4A
  mdns: default
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: false

That looks normal as far as I can tell. Well besides the network issue, of course. 
BobG
OP

 — Yesterday at 7:48 PM
ha dns info:
➜  ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.0.1
mdns: true
servers: []
update_available: false
version: 2026.02.0
version_latest: 2026.02.0

servers is empty. The ha dns options command from above should set that and also disable the fallback. 
BobG
OP
 — Yesterday at 7:50 PM
ha dns logs:

2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 201.0.168.192.in-addr.arpa. PTR: context deadline exceeded
2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:55315 - 20878 "PTR IN 203.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.339556554s
2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 203.0.168.192.in-addr.arpa. PTR: dial tcp 1.1.1.1:853: i/o timeout
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:40042 - 61403 "PTR IN 202.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.339147342s
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 202.0.168.192.in-addr.arpa. PTR: dial tcp 1.1.1.1:853: i/o timeout
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:51921 - 21010 "PTR IN 204.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.340063184999998s

message.txt
17 KB

That's a lot of timeouts.
Let's try something.
nslookup ghcr.io 1.1.1.1
nslookup ghcr.io 8.8.8.8
nslookup ghcr.io 192.168.0.1
Not sure why it uses 853 rather tahn just 53.
BobG
OP
 — Yesterday at 7:53 PM
➜  ~ nslookup ghcr.io 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.113.34
➜  ~ nslookup ghcr.io 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.114.34
➜  ~ nslookup ghcr.io 192.168.0.1
Server:         192.168.0.1
Address:        192.168.0.1#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.112.33

So normal DNS on port 53 works but the DNS plugins uses 853 and that seems to fail. Not completely sure how to disable that behavior but the commands above might work for this.
These: ⁠configuration⁠Supervisor 2026.05.0 and Core 2… 
BobG
OP
 — Yesterday at 7:58 PM

ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method

See if this DNS query works
dig +tls @1.1.1.1 ghcr.io
dig +tls @8.8.8.8 ghcr.io

ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method auto
BobG
OP
 — Yesterday at 8:02 PM
1st dns query
➜  ~ dig +tls @1.1.1.1 ghcr.io                                      

; <<>> DiG 9.20.22 <<>> +tls @1.1.1.1 ghcr.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13635
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; PADDING: (412 bytes)
;; QUESTION SECTION:
;ghcr.io.                       IN      A

;; ANSWER SECTION:
ghcr.io.                44      IN      A       140.82.112.34

;; Query time: 49 msec
;; SERVER: 1.1.1.1#853(1.1.1.1) (TLS)
;; WHEN: Mon May 18 20:02:22 EDT 2026
;; MSG SIZE  rcvd: 468

That works fine too 😐
I'm guessing the DNS plugin is at fault here then.
BobG
OP
 — Yesterday at 8:04 PM
here is the 2nd:
➜  ~ dig +tls @8.8.8.8 ghcr.io

; <<>> DiG 9.20.22 <<>> +tls @8.8.8.8 ghcr.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ghcr.io.                       IN      A

;; ANSWER SECTION:
ghcr.io.                60      IN      A       140.82.114.33

;; Query time: 69 msec
;; SERVER: 8.8.8.8#853(8.8.8.8) (TLS)
;; WHEN: Mon May 18 20:03:43 EDT 2026
;; MSG SIZE  rcvd: 52
Impact — Yesterday at 8:04 PM
What's ha dns info look like now?
BobG
OP
 — Yesterday at 8:05 PM
➜  ~ ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method auto
Command completed successfully.
I finally got it.. 👍
➜  ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
dns://192.168.0.1
dns://8.8.8.8
mdns: true
servers: []
update_available: false
version: 2026.02.0
version_latest: 2026.02.0
Impact — Yesterday at 8:07 PM
Fallback is still enabled and servers empty.
ha dns options --servers dns://8.8.8.8 --fallback=false
ha dns restart
You might also have to run ha supervisor reload or ha supervisor repair  but hopefully after that it works better and supervisor internet becomes true.
BobG
OP
 — Yesterday at 8:09 PM

Having multiple DNS servers is not bad but you generally want to have servers that respond in the same way.
I recommend only using your router's ip but we're trying to troubleshoot so we use a public one for now. 
BobG
OP

To elaborate a bit. Your local DNS server can likely resolve local DNS names of yourother devices which the public one cannot and therE's no real guratantee which one is used.
The commands do that. 
BobG
OP
 — Yesterday at 8:12 PM
➜  ~ ha dns options --servers dns://8.8.8.8 --fallback=false
Command completed successfully.
➜  ~ ha dns restart
Processing... Done.

Command completed successfully.

The 192.168.0.1 DNS likely comes from your router via DHCP (auto) but I don't want to set a static ip for now. That requires a bit of knowledge about your network to choose a proper one that doesn't conflict. 
BobG
OP
 — Yesterday at 8:13 PM
no problem

ha supervisor reload
ha supervisor repair
ha network info

Hopefully the bit at the end says true now. 
BobG
OP
 — Yesterday at 8:18 PM
It is TRUE!!!
➜  ~ ha supervisor reload     
Command completed successfully.
➜  ~ ha supervisor repair
Processing... Done.

Command completed successfully.
➜  ~ ha network info                                                    
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: end0
  ipv4:
    address:
    - 192.168.0.12/24
    gateway: 192.168.0.1
    method: auto
    nameservers:
    - 8.8.8.8
    - 192.168.0.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - fe80::9be5:893a:27ab:294e/64
    gateway: null
    ip6_privacy: default
    method: disabled
    nameservers: []
    ready: true
    route_metric: null
  llmnr: default
  mac: 20:F8:3B:01:1A:4A
  mdns: default
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: true

Finally some hope.
Let's try these then
ha core update
ha core info
ha supervisor logs

BobG
OP
 — Yesterday at 8:21 PM
here are the first two:
➜  ~ ha core update                                         
Processing... Done.

Command completed successfully.
➜  ~ ha core info  
arch: aarch64
audio_input: null
audio_output: null
backups_exclude_database: false
boot: true
duplicate_log_file: false
image: ghcr.io/home-assistant/green-homeassistant
ip_address: 172.30.32.1
machine: green
port: 8123
ssl: false
update_available: true
version: 2026.5.0
version_latest: 2026.5.2
watchdog: true

So it didn't update.
It's possible it takes a little bit as it does things in the background or a whole reboot helps but so far this still doesn't work.
BobG
OP
 — Yesterday at 8:23 PM
here is the supervisor log:
2026-05-18 19:43:18.848 INFO (MainThread) [supervisor.api.middleware.security] /dns/options access from a0d7b954_ssh
2026-05-18 19:44:18.190 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
2026-05-18 19:47:02.113 INFO (MainThread) [supervisor.api.middleware.security] /dns/info access from a0d7b954_ssh
2026-05-18 19:47:27.884 INFO (MainThread) [supervisor.api.middleware.security] /dns/logs access from a0d7b954_ssh
2026-05-18 19:47:36.300 INFO (MainThread) [supervisor.api.middleware.security] /dns/info access from a0d7b954_ssh
2026-05-18 19:48:40.432 INFO (MainThread) [supervisor.api.middleware.security] /dns/logs access from a0d7b954_ssh

message.txt
10 KB

Let's try another reboot. ha host reboot. 
BobG
OP
 — Yesterday at 8:26 PM
ok..reboot
in progress...takes a few.

Afterwards I'd try this again
ha core update --log-level debug --version 2026.5.2
ha supervisor logs

Otherwise I'm out of ideas for now. I'm betting docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2 works fine still. 
BobG
OP
 — Yesterday at 8:29 PM
sorry I did the reboot from GUI (not restart). Is that ok?

Sure. As long as it's a reboot and not a restart. 
BobG
OP
 — Yesterday at 8:30 PM
just finished reboot
➜  ~ ha core update --log-level debug --version 2026.5.2
2026/05/18 20:31:24 DEBUG Adding homedir to searchpath homedir=/root
2026/05/18 20:31:24 INFO No configfile found
2026/05/18 20:31:24 DEBUG Debug flags apiToken=cbc6929d0ab7bf065e26dcc886816c1a4630b21366fbb2dfbcb63dc5112946071308edd53d0a5f2c008edca8640237525d7b15a5b4ff043d cfgFile="" endpoint=supervisor logLevel=debug noProgress=false rawJSON=false
2026/05/18 20:31:24 DEBUG core update args=[]
2026/05/18 20:31:24 DEBUG [GenerateURI] base=supervisor section=core command=update
2026/05/18 20:31:24 DEBUG [GenerateURI] Result uri=http://supervisor/core/update url=http://supervisor/core/update url(string)=http://supervisor/core/update
2026/05/18 20:31:24 DEBUG Request body body=map[version:2026.5.2]
⣷ Processing... 2026/05/18 20:31:26 DEBUG Response statuscode=200 status="200 OK" time=1.97224002s received-at=2026-05-18T20:31:26.423-04:00 headers="map[Content-Length:[25] Content-Type:[application/json; charset=utf-8] Date:[Tue, 19 May 2026 00:31:26 GMT] Server:[Python/3.14 aiohttp/3.13.5]]" request="&{Method:POST URL:http://supervisor/core/update Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Accept:[application/json] Authorization:[Bearer cbc6929d0ab7bf065e26dcc886816c1a4630b21366fbb2dfbcb63dc5112946071308edd53d0a5f2c008edca8640237525d7b15a5b4ff043d] Content-Type:[application/json] User-Agent:[go-resty/2.17.2 (https://github.com/go-resty/resty)]] Body:{Reader:} GetBody:0x21c280 ContentLength:22 TransferEncoding:[] Close:false Host:supervisor Form:map[] PostForm:map[] MultipartForm:<nil> Trailer:map[] RemoteAddr: RequestURI: TLS:<nil> Cancel:<nil> Response:<nil> Pattern: ctx:{emptyCtx:{}} pat:<nil> matches:[] otherValues:map[]}" body="{\"result\":\"ok\",\"data\":{}}"
Processing... Done.

Command completed successfully.
Here is the supervisor log
➜  ~ ha supervisor logs | more                          
2026-05-18 20:28:44.624 WARNING (SyncWorker_6) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of MQTT IO
2026-05-18 20:28:44.624 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'MQTT IO' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-18 20:28:44.635 WARNING (SyncWorker_6) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of Log Viewer
2026-05-18 20:28:44.635 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'Log Viewer' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-18 20:28:44.653 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'SQLite Web' uses deprecated 'advanced' field in config. This field is ignored by the Supervisor. Please report this to the maintainer.

message.txt
14 KB


This whole section makes me unhappy
2026-05-18 20:31:24.745 INFO (MainThread) [supervisor.docker.interface] Updating image ghcr.io/home-assistant/green-homeassistant:2026.5.0 to ghcr.io/home-assistant/green-homeassistant:2026.5.2
2026-05-18 20:31:25.096 WARNING (MainThread) [supervisor.docker.manifest] Failed to get token from https://ghcr.io/token: 403
2026-05-18 20:31:25.150 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/home-assistant/green-homeassistant:2026.5.2 - 401
2026-05-18 20:31:25.150 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/green-homeassistant with tag 2026.5.2.
2026-05-18 20:31:25.759 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/green-homeassistant:2026.5.2: [403] error from registry: denied
2026-05-18 20:31:25.760 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed
BobG
OP
 — Yesterday at 8:37 PM
that section is always the same.  [401] [403] denied.  it was the same for Supervisor

Does docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2 work?
I'm not really sure what else to try at this point.
BobG
OP

 — Yesterday at 8:43 PM
it is pulling data..waiting to complete

So normal docker stuff still works.
You likely need someone more familiar with supervisor internals here.
BobG
OP
 — Yesterday at 8:44 PM
still downloading one is 373.3MB
do you have any suggestions how to get someone with supervisor internal vs. fishing on the forums...

In theory ha core rebuild will just use what you just downloaded or at least on the next reboot but this is more of a workaround.
Nope.
BobG
OP
 — Yesterday at 8:47 PM
Interesting.. it seemed to be struggling downloading the big file and then it stopped at 69.72MB/373.3MB
here is the screen
➜  ~ docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2
2026.5.2: Pulling from home-assistant/green-homeassistant
42c893e3df36: Download complete 
d2cece6c64c7: Pull complete 
6e9b027841cc: Pull complete 
291125ae7f2d: Pull complete 
0b5f60265c2e: Downloading [=========>                                         ]  69.72MB/373.3MB
10166dc21203: Pull complete 
0c60185c088f: Download complete 
3a7d897e37b9: Pull complete 
7c8f7ac76ce6: Download complete 
0cedb70087f6: Download complete 
failed to copy: read tcp 192.168.0.12:44986->185.199.109.154:443: read: connection reset by peer

There are several message.txt files that the forum automatically created since the text was over a page. If you need something, I can try to go to the forum and pull the data in the file.

Again, thanks for the response and any assistance you can provide.

16

@boheme61

Thank you for your response and I do really appreciate your assistance.

I do not have a 'structured' approach because this is my first rodeo. I have not had this type of issue before, so I do not have a plan but instead making a plan as we go since I am flying by the seat of my pants.

I am not a schooled software person but instead hardware guy who has worked in the computer field starting in 1977 (yes 1977, PC's were a glimmer in someone's eye). I was a hard drive service 'expert' (3MB, 10MB, 50MB and 200MB). I saw some customers lose it because their hard drive crashed and they did not have a backup. Through this experience, I have picked up on software/operating systems but from a 100 mile view and not in the weeds. Likewise, I also have a sense of caution at times and try to make sure I have a parachute before I jump off the cliff. I would rather not have a brick when I am done or have to rebuild the 100+ automations, helpers, integrations, etc..

Anyways, I have been working with another user (not AI), and he was the one who got Supervisor to update but cannot seem to get Core to update. We worked again last night for a couple of hours but feels he has exhausted all of his tricks, and that I am in need of someone knowledgeable of Supervisor internals.

Here is the session:


ha supervisor options --channel stable
ha refresh-updates
ha available-updates
ha core info

Can you check these? 
You can also try if we can see more info via debug log levels
ha core update --log-level debug
ha supervisor update --log-level debug
 
In the past users also did a downgrade and then a upgrade but I was trying to avoid having you jump through a bunch of such hoops.
I was kinda hoping someone else would jump in with a solution.
Maybe there's a known issue I'm not aware of for example.
This would update to a specific version
ha core update --log-level debug --version 2026.5.2

System is ready! Use browser or app to configure.
➜  ~ ha supervisor options --channel stable                                
Command completed successfully.

➜  ~ ha refresh-updates                    
Command completed successfully.

message.txt
5 KB

If you check the versions here you are on the latest ones: https://github.com/home-assistant/version/blob/4b64ed71d3aa6eba6efeb004235eabf87a812c46/stable.json 
At least for supervisor. If core really was successful then ha core info should show that to be version: 2026.5.2 now too. 
BobG
OP
 — Yesterday at 7:17 PM
I sent the outputs and it put them into an attachment file message.txt.  Anyways, ha core info states: update_available: true
version: 2026.5.0
version_latest: 2026.5.2

:<
Let's check ha supervisor logs and ha host logs again.
BobG
OP
 — Yesterday at 7:18 PM
Here is ha core update --log-level debug --version 2026.5.2  ➜  ~ ha core update --log-level debug --version 2026.5.2
2026/05/18 19:11:59 DEBUG Adding homedir to searchpath homedir=/root
2026/05/18 19:11:59 INFO No configfile found
2026/05/18 19:11:59 DEBUG Debug flags apiToken=bad46b1d38f2ccabaf0439b1623a104a0709031cd1f1ae143bd7ce63b95477c3e6be81a5827adc0ade0765566dbd1abec54ba242460ba5d6 cfgFile="" endpoint=supervisor logLevel=debug noProgress=false rawJSON=false
2026/05/18 19:11:59 DEBUG core update args=[]
2026/05/18 19:11:59 DEBUG [GenerateURI] base=supervisor section=core command=update
2026/05/18 19:11:59 DEBUG [GenerateURI] Result uri=http://supervisor/core/update url=http://supervisor/core/update url(string)=http://supervisor/core/update
⣾ Processing... 2026/05/18 19:11:59 DEBUG Request body body=map[version:2026.5.2]
⣻ Processing... 2026/05/18 19:12:03 DEBUG Response statuscode=200 status="200 OK" time=4.319794534s received-at=2026-05-18T19:12:03.788-04:00 headers="map[Content-Length:[25] Content-Type:[application/json; charset=utf-8] Date:[Mon, 18 May 2026 23:12:03 GMT] Server:[Python/3.14 aiohttp/3.13.5]]" request="&{Method:POST URL:http://supervisor/core/update Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Accept:[application/json] Authorization:[Bearer bad46b1d38f2ccabaf0439b1623a104a0709031cd1f1ae143bd7ce63b95477c3e6be81a5827adc0ade0765566dbd1abec54ba242460ba5d6] Content-Type:[application/json] User-Agent:[go-resty/2.17.2 (https://github.com/go-resty/resty)]] Body:{Reader:} GetBody:0x21c280 ContentLength:22 TransferEncoding:[] Close:false Host:supervisor Form:map[] PostForm:map[] MultipartForm:<nil> Trailer:map[] RemoteAddr: RequestURI: TLS:<nil> Cancel:<nil> Response:<nil> Pattern: ctx:{emptyCtx:{}} pat:<nil> matches:[] otherValues:map[]}" body="{"result":"ok","data":{}}"
Processing... Done.

Command completed successfully.

BobG
OP
 — Yesterday at 7:25 PM
I probably had a network outage around 6:36 / 18:36.  I received a email that a hub for some devices on HA went offline and my wife is watching TV (streaming via Roku) and it went down.  It is back up again.  As with any internet this can happen but it does not happen often.
should I rerun anything again before I rerun ha supervisor logs and ha host logs again

No.
BobG
OP
 — Yesterday at 7:27 PM
here is ha supervisor logs from 18:42
2026-05-18 18:42:15.917 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disk_lifetime/system
2026-05-18 18:42:15.924 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_ipv6_error/dns_server
2026-05-18 18:42:18.761 INFO (MainThread) [supervisor.resolution.checks.base] Run check for pwned/addon
2026-05-18 18:42:18.762 INFO (MainThread) [supervisor.resolution.checks.base] Run check for free_space/system
2026-05-18 18:42:18.765 INFO (MainThread) [supervisor.resolution.checks.base] Run check for multiple_data_disks/system
2026-05-18 18:42:18.766 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_failed/dns_server

message.txt
8 KB
here is the ha host logs from 18:22
2026-05-18 22:11:38.539 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/sbc_xq_512
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSink/sbc_xq_552
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/sbc_xq_552
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSink/faststream
2026-05-18 22:11:38.540 homeassistant bluetoothd[474]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource/faststream
2026-05-18 22:11:38.554 homeassistant bluetoothd[474]: Destroy Adv Monitor Manager

message.txt
8 KB
Does that work or do you need something else.

That's fine.
The no supervisor internet connection is peculiar. What does ha network info say?
BobG
OP
 — Yesterday at 7:37 PM
Here it is:  
➜  ~ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
connected: true
enabled: true
interface: end0
ipv4:
  address:
192.168.0.12/24
gateway: 192.168.0.1
method: auto
nameservers:
192.168.0.1
ready: true
route_metric: null
ipv6:
  addr_gen_mode: default
  address:
fe80::9be5:893a:27ab:294e/64
gateway: null
ip6_privacy: default
method: disabled
nameservers: []
ready: true
route_metric: null
llmnr: default
mac: 20:F8:3B:01:1A:4A
mdns: default
primary: true
type: ethernet
vlan: null
wifi: null
supervisor_internet: false


This is not good
supervisor_internet: false
Check
ha dns info
ha dns logs
BobG
OP


You can also try this
ha network update end0 --ipv4-nameserver 8.8.8.8
ha dns options --servers dns://8.8.8.8 --fallback=false
ha dns restart

and see if that changes. HA does something similar like this to see if you have internet connectivity so try this before and after
curl http://checkonline.home-assistant.io/online.txt

BobG
OP
 — Yesterday at 7:41 PM
➜  ~ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: end0
  ipv4:
    address:
    - 192.168.0.12/24
    gateway: 192.168.0.1
    method: auto
    nameservers:
    - 192.168.0.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - fe80::9be5:893a:27ab:294e/64
    gateway: null
    ip6_privacy: default
    method: disabled
    nameservers: []
    ready: true
    route_metric: null
  llmnr: default
  mac: 20:F8:3B:01:1A:4A
  mdns: default
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: false

That looks normal as far as I can tell. Well besides the network issue, of course. 
BobG
OP

 — Yesterday at 7:48 PM
ha dns info:
➜  ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.0.1
mdns: true
servers: []
update_available: false
version: 2026.02.0
version_latest: 2026.02.0

servers is empty. The ha dns options command from above should set that and also disable the fallback. 
BobG
OP
 — Yesterday at 7:50 PM
ha dns logs:

2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 201.0.168.192.in-addr.arpa. PTR: context deadline exceeded
2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:55315 - 20878 "PTR IN 203.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.339556554s
2026-05-18 23:06:14.637 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 203.0.168.192.in-addr.arpa. PTR: dial tcp 1.1.1.1:853: i/o timeout
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:40042 - 61403 "PTR IN 202.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.339147342s
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [ERROR] plugin/errors: 2 202.0.168.192.in-addr.arpa. PTR: dial tcp 1.1.1.1:853: i/o timeout
2026-05-18 23:06:14.638 homeassistant hassio_dns[576]: [INFO] 127.0.0.1:51921 - 21010 "PTR IN 204.0.168.192.in-addr.arpa. udp 44 false 512" - - 0 24.340063184999998s

message.txt
17 KB

That's a lot of timeouts.
Let's try something.
nslookup ghcr.io 1.1.1.1
nslookup ghcr.io 8.8.8.8
nslookup ghcr.io 192.168.0.1
Not sure why it uses 853 rather tahn just 53.
BobG
OP
 — Yesterday at 7:53 PM
➜  ~ nslookup ghcr.io 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.113.34
➜  ~ nslookup ghcr.io 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.114.34
➜  ~ nslookup ghcr.io 192.168.0.1
Server:         192.168.0.1
Address:        192.168.0.1#53

Non-authoritative answer:
Name:   ghcr.io
Address: 140.82.112.33

So normal DNS on port 53 works but the DNS plugins uses 853 and that seems to fail. Not completely sure how to disable that behavior but the commands above might work for this.
These: ⁠configuration⁠Supervisor 2026.05.0 and Core 2… 
BobG
OP
 — Yesterday at 7:58 PM

ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method

See if this DNS query works
dig +tls @1.1.1.1 ghcr.io
dig +tls @8.8.8.8 ghcr.io

ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method auto
BobG
OP
 — Yesterday at 8:02 PM
1st dns query
➜  ~ dig +tls @1.1.1.1 ghcr.io                                      

; <<>> DiG 9.20.22 <<>> +tls @1.1.1.1 ghcr.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13635
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; PADDING: (412 bytes)
;; QUESTION SECTION:
;ghcr.io.                       IN      A

;; ANSWER SECTION:
ghcr.io.                44      IN      A       140.82.112.34

;; Query time: 49 msec
;; SERVER: 1.1.1.1#853(1.1.1.1) (TLS)
;; WHEN: Mon May 18 20:02:22 EDT 2026
;; MSG SIZE  rcvd: 468

That works fine too 😐
I'm guessing the DNS plugin is at fault here then.
BobG
OP
 — Yesterday at 8:04 PM
here is the 2nd:
➜  ~ dig +tls @8.8.8.8 ghcr.io

; <<>> DiG 9.20.22 <<>> +tls @8.8.8.8 ghcr.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ghcr.io.                       IN      A

;; ANSWER SECTION:
ghcr.io.                60      IN      A       140.82.114.33

;; Query time: 69 msec
;; SERVER: 8.8.8.8#853(8.8.8.8) (TLS)
;; WHEN: Mon May 18 20:03:43 EDT 2026
;; MSG SIZE  rcvd: 52
Impact — Yesterday at 8:04 PM
What's ha dns info look like now?
BobG
OP
 — Yesterday at 8:05 PM
➜  ~ ha network update end0 --ipv4-nameserver 8.8.8.8 --ipv4-method auto
Command completed successfully.
I finally got it.. 👍
➜  ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
dns://192.168.0.1
dns://8.8.8.8
mdns: true
servers: []
update_available: false
version: 2026.02.0
version_latest: 2026.02.0
Impact — Yesterday at 8:07 PM
Fallback is still enabled and servers empty.
ha dns options --servers dns://8.8.8.8 --fallback=false
ha dns restart
You might also have to run ha supervisor reload or ha supervisor repair  but hopefully after that it works better and supervisor internet becomes true.
BobG
OP
 — Yesterday at 8:09 PM

Having multiple DNS servers is not bad but you generally want to have servers that respond in the same way.
I recommend only using your router's ip but we're trying to troubleshoot so we use a public one for now. 
BobG
OP

To elaborate a bit. Your local DNS server can likely resolve local DNS names of yourother devices which the public one cannot and therE's no real guratantee which one is used.
The commands do that. 
BobG
OP
 — Yesterday at 8:12 PM
➜  ~ ha dns options --servers dns://8.8.8.8 --fallback=false
Command completed successfully.
➜  ~ ha dns restart
Processing... Done.

Command completed successfully.

The 192.168.0.1 DNS likely comes from your router via DHCP (auto) but I don't want to set a static ip for now. That requires a bit of knowledge about your network to choose a proper one that doesn't conflict. 
BobG
OP
 — Yesterday at 8:13 PM
no problem

ha supervisor reload
ha supervisor repair
ha network info

Hopefully the bit at the end says true now. 
BobG
OP
 — Yesterday at 8:18 PM
It is TRUE!!!
➜  ~ ha supervisor reload     
Command completed successfully.
➜  ~ ha supervisor repair
Processing... Done.

Command completed successfully.
➜  ~ ha network info                                                    
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: end0
  ipv4:
    address:
    - 192.168.0.12/24
    gateway: 192.168.0.1
    method: auto
    nameservers:
    - 8.8.8.8
    - 192.168.0.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - fe80::9be5:893a:27ab:294e/64
    gateway: null
    ip6_privacy: default
    method: disabled
    nameservers: []
    ready: true
    route_metric: null
  llmnr: default
  mac: 20:F8:3B:01:1A:4A
  mdns: default
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: true

Finally some hope.
Let's try these then
ha core update
ha core info
ha supervisor logs

BobG
OP
 — Yesterday at 8:21 PM
here are the first two:
➜  ~ ha core update                                         
Processing... Done.

Command completed successfully.
➜  ~ ha core info  
arch: aarch64
audio_input: null
audio_output: null
backups_exclude_database: false
boot: true
duplicate_log_file: false
image: ghcr.io/home-assistant/green-homeassistant
ip_address: 172.30.32.1
machine: green
port: 8123
ssl: false
update_available: true
version: 2026.5.0
version_latest: 2026.5.2
watchdog: true

So it didn't update.
It's possible it takes a little bit as it does things in the background or a whole reboot helps but so far this still doesn't work.
BobG
OP
 — Yesterday at 8:23 PM
here is the supervisor log:
2026-05-18 19:43:18.848 INFO (MainThread) [supervisor.api.middleware.security] /dns/options access from a0d7b954_ssh
2026-05-18 19:44:18.190 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
2026-05-18 19:47:02.113 INFO (MainThread) [supervisor.api.middleware.security] /dns/info access from a0d7b954_ssh
2026-05-18 19:47:27.884 INFO (MainThread) [supervisor.api.middleware.security] /dns/logs access from a0d7b954_ssh
2026-05-18 19:47:36.300 INFO (MainThread) [supervisor.api.middleware.security] /dns/info access from a0d7b954_ssh
2026-05-18 19:48:40.432 INFO (MainThread) [supervisor.api.middleware.security] /dns/logs access from a0d7b954_ssh

message.txt
10 KB

Let's try another reboot. ha host reboot. 
BobG
OP
 — Yesterday at 8:26 PM
ok..reboot
in progress...takes a few.

Afterwards I'd try this again
ha core update --log-level debug --version 2026.5.2
ha supervisor logs

Otherwise I'm out of ideas for now. I'm betting docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2 works fine still. 
BobG
OP
 — Yesterday at 8:29 PM
sorry I did the reboot from GUI (not restart). Is that ok?

Sure. As long as it's a reboot and not a restart. 
BobG
OP
 — Yesterday at 8:30 PM
just finished reboot
➜  ~ ha core update --log-level debug --version 2026.5.2
2026/05/18 20:31:24 DEBUG Adding homedir to searchpath homedir=/root
2026/05/18 20:31:24 INFO No configfile found
2026/05/18 20:31:24 DEBUG Debug flags apiToken=cbc6929d0ab7bf065e26dcc886816c1a4630b21366fbb2dfbcb63dc5112946071308edd53d0a5f2c008edca8640237525d7b15a5b4ff043d cfgFile="" endpoint=supervisor logLevel=debug noProgress=false rawJSON=false
2026/05/18 20:31:24 DEBUG core update args=[]
2026/05/18 20:31:24 DEBUG [GenerateURI] base=supervisor section=core command=update
2026/05/18 20:31:24 DEBUG [GenerateURI] Result uri=http://supervisor/core/update url=http://supervisor/core/update url(string)=http://supervisor/core/update
2026/05/18 20:31:24 DEBUG Request body body=map[version:2026.5.2]
⣷ Processing... 2026/05/18 20:31:26 DEBUG Response statuscode=200 status="200 OK" time=1.97224002s received-at=2026-05-18T20:31:26.423-04:00 headers="map[Content-Length:[25] Content-Type:[application/json; charset=utf-8] Date:[Tue, 19 May 2026 00:31:26 GMT] Server:[Python/3.14 aiohttp/3.13.5]]" request="&{Method:POST URL:http://supervisor/core/update Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Accept:[application/json] Authorization:[Bearer cbc6929d0ab7bf065e26dcc886816c1a4630b21366fbb2dfbcb63dc5112946071308edd53d0a5f2c008edca8640237525d7b15a5b4ff043d] Content-Type:[application/json] User-Agent:[go-resty/2.17.2 (https://github.com/go-resty/resty)]] Body:{Reader:} GetBody:0x21c280 ContentLength:22 TransferEncoding:[] Close:false Host:supervisor Form:map[] PostForm:map[] MultipartForm:<nil> Trailer:map[] RemoteAddr: RequestURI: TLS:<nil> Cancel:<nil> Response:<nil> Pattern: ctx:{emptyCtx:{}} pat:<nil> matches:[] otherValues:map[]}" body="{\"result\":\"ok\",\"data\":{}}"
Processing... Done.

Command completed successfully.
Here is the supervisor log
➜  ~ ha supervisor logs | more                          
2026-05-18 20:28:44.624 WARNING (SyncWorker_6) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of MQTT IO
2026-05-18 20:28:44.624 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'MQTT IO' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-18 20:28:44.635 WARNING (SyncWorker_6) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of Log Viewer
2026-05-18 20:28:44.635 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'Log Viewer' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-18 20:28:44.653 WARNING (SyncWorker_6) [supervisor.addons.validate] App 'SQLite Web' uses deprecated 'advanced' field in config. This field is ignored by the Supervisor. Please report this to the maintainer.

message.txt
14 KB


This whole section makes me unhappy
2026-05-18 20:31:24.745 INFO (MainThread) [supervisor.docker.interface] Updating image ghcr.io/home-assistant/green-homeassistant:2026.5.0 to ghcr.io/home-assistant/green-homeassistant:2026.5.2
2026-05-18 20:31:25.096 WARNING (MainThread) [supervisor.docker.manifest] Failed to get token from https://ghcr.io/token: 403
2026-05-18 20:31:25.150 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/home-assistant/green-homeassistant:2026.5.2 - 401
2026-05-18 20:31:25.150 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/green-homeassistant with tag 2026.5.2.
2026-05-18 20:31:25.759 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/green-homeassistant:2026.5.2: [403] error from registry: denied
2026-05-18 20:31:25.760 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed
BobG
OP
 — Yesterday at 8:37 PM
that section is always the same.  [401] [403] denied.  it was the same for Supervisor

Does docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2 work?
I'm not really sure what else to try at this point.
BobG
OP

 — Yesterday at 8:43 PM
it is pulling data..waiting to complete

So normal docker stuff still works.
You likely need someone more familiar with supervisor internals here.
BobG
OP
 — Yesterday at 8:44 PM
still downloading one is 373.3MB
do you have any suggestions how to get someone with supervisor internal vs. fishing on the forums...

In theory ha core rebuild will just use what you just downloaded or at least on the next reboot but this is more of a workaround.
Nope.
BobG
OP
 — Yesterday at 8:47 PM
Interesting.. it seemed to be struggling downloading the big file and then it stopped at 69.72MB/373.3MB
here is the screen
➜  ~ docker pull ghcr.io/home-assistant/green-homeassistant:2026.5.2
2026.5.2: Pulling from home-assistant/green-homeassistant
42c893e3df36: Download complete 
d2cece6c64c7: Pull complete 
6e9b027841cc: Pull complete 
291125ae7f2d: Pull complete 
0b5f60265c2e: Downloading [=========>                                         ]  69.72MB/373.3MB
10166dc21203: Pull complete 
0c60185c088f: Download complete 
3a7d897e37b9: Pull complete 
7c8f7ac76ce6: Download complete 
0cedb70087f6: Download complete 
failed to copy: read tcp 192.168.0.12:44986->185.199.109.154:443: read: connection reset by peer

There are several message.txt files that I should be able to pull if needed.
Likewise, I can probably pull the session from the time when Supervisor updated.

I am very cautious. As I stated above, I would rather not start over and rebuild HA. I do have backups from before this started and as recent as Monday on a Win11 PC. I also have USB memory sticks and SD cards, if needed. Also, I now have a screen and keyboard on HA Green but I have not worked in this 'interface' before. This does not stop me from doing things directly in HA (CLI) but I will need more 'guidance'.

Everyone tends to troubleshoot differently. Everything I have done is because I am reliant on others like you and in some cases AI. As they troubleshoot different than you and I, sometime things were done that you may not agree with but at the same time they were doing the best that they could, and I do appreciate it.

I trust if you look at the session I attached above that you can come to the same conclusion as the person (not AI) that I was working with that the issue is Supervisor internal for which if you have that experience level, I would be eternally grateful.

Do you have a plan that I can use? We can move to another forum where it is a 'chat' mode vs. the current comment mode. Otherwise, feel free to offer some steps or suggestions.

17

The problem has been resolved.

It is suspected that during an app update registry credentials were added that conflicted with Core and Supervisor updates.

In my case there were two entries that I deleted and rebooted the system for good measure.

Afterwards the Core update worked as normal and is now 2026.5.3.

18

An investment in an UPS may be on your horizon.

What were the two entries? How did they get there?

Maybe unreliable power was the underlying cause all along, a docker corruption that affected everything running on top of it.

As a final bookend to your saga, please advise if the latest core update (2026.5.3 just released) worked without any 'behind the scenes tickling' on your part.

19

..and yet another core update a few hours ago for verification.

20

One thing for sure, Bobg didn’t mark a “Solution” As Solution, but a “Troubleshooting Session” prior to his “suspected” cause
So this “case” is of no help to others who might end up in the same situation