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
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 !, as i doubt you have reasons to involve your router for this.
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.