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:
- create encrypted backups,
- download the backup locally,
- save the backup encryption key,
- verify the backup file exists,
- 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:
- Update/upgrade failure occurred.
- Recovery image appeared to hang at time synchronization.
- System eventually booted anyway.
- Existing onboarding/authentication state survived recovery.
- Authentication database became inconsistent/corrupted.
- Onboarding still incorrectly claimed setup was complete.
- Removing stale onboarding state restored true first-run onboarding.
- Home Assistant became fully functional again.
I hope this helps.