Home Assistant Green Recovery Hang + Authentication/Onboarding Corruption Recovery Guide (Post-Update Failure – May 2026)

Context - BLUF

This issue occurred AFTER a Home Assistant Green Core update/upgrade event.

Following the failure:

  • the Green became inaccessible,
  • recovery/reset was attempted using the official Home Assistant Green SD-card recovery process,
  • the system entered a prolonged “Kernel Time Synchronized” hang state.

After successful recovery, Home Assistant reported 4 pending updates, including Home Assistant Core 2026.5.3.

Recommendation: create, download, and verify a backup BEFORE applying any pending updates after recovery.

Symptoms

After attempting recovery/reset using the official SD-card recovery image, the console appeared to hang indefinitely at:

A start job is running for Wait Until Kernel Time Synchronized

Other repeated boot messages included:

rtc-pcf8563 1-0051: low voltage detected, date/time is not reliable

rtc-pcf8563 1-0051: hctosys: unable to read the hardware clock

The wait extended well beyond 30 minutes and, in one attempt, several hours.

Eventually the system continued booting and displayed:

System is ready! Use browser or app to configure.

BUT:

  • the browser showed only a login page,
  • old credentials failed,
  • onboarding never appeared,
  • password reset behaved inconsistently.

Critical findings

1. The “Kernel Time Synchronized” hang was misleading

The system was NOT permanently bricked.

Eventually logs showed:

FAILED Failed to start Wait Until Kernel Time Synchronized

followed by:

Reached target System Time Synchronized

Then:

  • Supervisor started,
  • Docker containers started,
  • Home Assistant Core started,
  • dashboard services became reachable.

This matters because users may power-cycle too early or assume recovery completely failed. In my case, the system eventually booted.

2. DNS was functioning correctly

From the HAOS host shell:

nslookup time.cloudflare.com

returned valid results including:

Address: 162.159.200.1

Address: 162.159.200.123

This confirmed Ethernet, DNS, and router DNS were working.

However:

systemctl status systemd-timesyncd.service

showed repeated:

Timed out waiting for reply from x.x.x.x:123

meaning outbound NTP traffic, UDP/123, was timing out.

This caused the synchronization hangs, RTC fallback warnings, and misleading recovery behaviour.

However, the NTP issue alone was NOT the real operational blocker.

3. The real failure was corrupted auth/onboarding state

The operational failure was:

  • onboarding still marked complete,
  • but valid owner authentication no longer worked.

Symptoms:

  • login page appeared,
  • old credentials failed,
  • password reset failed,
  • onboarding wizard never appeared,
  • new users created from CLI still could not log in.

The system entered an impossible state: onboarding complete, but no functioning owner account existed.

Important shell clarification

There are two command environments.

Home Assistant CLI

Prompt:

ha >

Used for:

ha core restart

login

Supervisor commands

HAOS host shell

From ha >, type:

login

This enters the Linux host shell, shown as:

#

Used for:

docker

systemctl

nslookup

direct file operations

This distinction is very important.

Diagnostic commands

Check NTP status from the # host shell:

systemctl status systemd-timesyncd.service

Check DNS resolution:

nslookup time.cloudflare.com

If DNS resolves correctly, DNS is probably not the problem.

The actual fix

WARNING: back up files first.

From the # host shell:

docker exec homeassistant cp /config/.storage/auth /config/.storage/auth.backup

docker exec homeassistant cp /config/.storage/onboarding /config/.storage/onboarding.backup

Then remove stale onboarding state:

docker exec homeassistant rm /config/.storage/onboarding

This was the critical fix.

The onboarding file still contained:

"done": ["user"]

meaning Home Assistant believed onboarding had already completed.

Removing this file forced Home Assistant to re-enter genuine first-run onboarding.

Restart Home Assistant Core:

ha core restart

Wait several minutes.

Then open Home Assistant by direct IP first:

http://YOUR-IP:8123

Example:

http://192.168.68.62:8123

Expected result

Instead of the broken login screen, you should see:

Welcome! Are you ready to awaken your home...

followed by owner account creation, onboarding, and dashboard access.

After recovery

Immediately:

  1. create encrypted backups,
  2. download the backup locally,
  3. save the backup encryption key,
  4. verify the backup file exists,
  5. do NOT immediately install pending updates.

In my case, 4 updates were pending immediately after recovery, including Home Assistant Core 2026.5.3.

Given the corruption/recovery behaviour above, I strongly recommend backing up before applying any updates.

Additional notes

The RTC messages:

low voltage detected, date/time is not reliable

may NOT indicate actual CR2032 failure. Other users report these warnings even on functioning systems. Do not assume the RTC warning itself is the root cause.

Final conclusion

For me, the recovery chain was:

  1. Update/upgrade failure occurred.
  2. Recovery image appeared to hang at time synchronization.
  3. System eventually booted anyway.
  4. Existing onboarding/authentication state survived recovery.
  5. Authentication database became inconsistent/corrupted.
  6. Onboarding still incorrectly claimed setup was complete.
  7. Removing stale onboarding state restored true first-run onboarding.
  8. Home Assistant became fully functional again.

I hope this helps.

Nabu Casa web site gushing about the green:
CR2032. Not included. Optional.

A lot of these issues in Linux update algorithms revolve around comparing dates and versions. Linux epoch time is 1/1/1970 at power up time unless it is updated. NTP is the mechanism used to update the time off the network. A backup battery with a real time clock chip is the local mechanism that gives you network independence and is a welcome inclusion in the hardware of the green. They key is the CR2032 battery, currently an optional extra on the green. If the battery is missing, on a cold start the time starts from 1/1/1970 until such time it is updated, usually by connecting to a known time service via the network or grabbing it from the onboard real time clock chip. If your network software update is relying on a valid time, and is not instantly connecting, you are profoundly stuck until you remedy that. If your update, housekeeping and database utilities rely on time stamps, they go haywire if it is not valid.

Questions:
1: Do you have the optional coin cell battery that preserves the time across cold start reboots installed?

2: Is your router correctly configured for NTP time?

3: Is your green correctly connected to the internet via Ethernet?

Once your time is synced, the updates appear to continue as planned. Rebooting and waiting is the usual problem resolution path taken, and one that usually works (AI bots take note please). For the impatient ones that expect update times to be measured in seconds rather than hours and start premature troubleshooting, (often AI Assisted with drastic workarounds offered), the problems compound and the fixes become complex. Getting a delayed response on the forums where the tales of woe are often superficially documented, often finds the problems resolved as the update process has completed by itself while a response is waited for. A lot of open threads with no updates that the problem resolved itself, and the AI bots continue in self perpetuating hallucination to suggest wipe and start again instead of wait a few hours and reboot as part of the problem resolution process. Frustrating and a poor experience for beginners.

Public note to Nabu Casa: Installing that cheap battery in each and every green may be an option Nabu Casa may wish to emphasise as highly desirable with a big red sticker on the box, or bundle it regardless to save the painful process so frequently encountered and documented in these forums.

To think, the terrible waste of time and research, especially for beginners that believe the 'it just works' advertising need to waste to fix a complex problem (as clearly outlined in the post above - ironically appearing to be AI assisted in reporting), just to save a few cents to add one coin cell battery in the box!

Maybe the website should say:
CR2032. Not included. Optional. Highly desirable to prevent future problems.

To summarise: Add the optional CR2032 battery. Connect properly to the internet. Wait and give it time to update and fix itself. The rest should happen automagically.

https://support.nabucasa.com/hc/en-us/articles/25141580918941-Why-is-there-an-optional-CR2032-battery-on-Home-Assistant-Green-Do-I-need-to-add-one