Constant reboot after 2026.9 update

I’ve been monitoring this 9.0 issue for a couple of days now and am running 8.3 from a backup restore. I’m running HAOS in a Proxmox VM, with a dedicated domain and Cloudflare Zero Trust tunnel. I’m having two problems. 1) the 9.0 issue of the main page not loading, and 2) an error when going to Settings - Devices and services which says “Error while loading page integrations”. I do not have this 2nd error when accessing HAOS via IP address on my LAN (http vs. https).

UPDATE: I’ve disabled the Cloudflared Tunnel App and am using a CNAME and Reverse Proxy. This has fixed the 2nd error above. Seems like there may be a Cloudflared issue.

How to see if you are impacted with those bloated deleted devices? Where are the stores? And how to see them?

My system doesn’t seem to reboot, just refresh the dashboard constantly.

I get

Logger: py.warnings
Source: /usr/local/lib/python3.14/\_py_warnings.py:230 
First occurred: 07:55:16 (18 occurrences) 
Last logged: 07:58:10

 /usr/local/lib/python3.14/site-packages/urllib3/connectionpool.py:1110: InsecureRequestWarning: Unverified HTTPS request is being made to host '<domain name here>'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#tls-warnings warnings.warn(

This has been an issue for many including myself.

The issue resides in a custom component in the configuration.yaml file.

look here:

https://community.home-assistant.io/t/2026-9-theres-room-on-this-bus/1023661/162?u=wgumaa

and here:

https://github.com/issues/recent?issue=home-assistant%7Ccore%7C181149&issue_global_id=I_kwDOAMSroc8AAAABPfbwww

.storage , as you already somehow have misunderstood/misreads " stores " this procedure is not recommended ( for You ) :wink:

/config/.storage/core.device_registry

Just do a simple “count row/entries” , or scroll and leave it “un touch(ed)”

So i Thought i’d try to check for deleted devices,

My core.device_registry file was 577MB with 1.6M odd lines of deleted entities…

Now it has 2, with a file size of 202KB :smiley:

Just for reference though, i did try to update again to 2026.9, and the crashing and restarts are still there.

Edit: Also the system appears to be using half the RAM it was using before, sitting at around 4GB total now, nice!!!

9.1 is out. I’ve updated and it seems to be working well. I’ll be testing today.

So, i thought “I should wait until i get home to try this!!”

But no!!! i clicked on update and i’m running 2026.9.1 now…

Seems to be stable so far, but it’s only been 10 mins, we’ll see how it goes

No restarts, no memory bloat, everything is working, and seems to be working better than ever.

I think i’m all done, will take another backup :smiley:

What did you do to get rid of the orphaned devices? Did you just clear the whole file, or did you filter in jq?

The File has a defined split between current and deleted items:

i just cleared all but the last few, saved and restarted

As i had 1.6M deleted items, i had to download the file, edit in notepad++ and then upload the replacement.

What is the exact location of the file? Thx.

Doesn’t the Spook HACS app integration add the capability to the system/tools/actions to identify and purge entities without directly modifying files, with the risk of typos wiping everything? If not, could it?

[Edited for @boheme61 prompting. It’s all just Python anyway, isnt it, behind the scenes? No LLMs were harmed, abused, or even distracted in this post - it is an original work, unassisted by any artificial assistance.]

I wryly note Frenck is the author of Spook as well as the update code you blithely hit continue on, that efficiently nuked your database without further ado. I’m sure he could whip up a rescue package for you to bypass manual modification with all the risks mistyping something involves and add it to Spook in the next release to expunge the extraneous data that seems to have crept in.

Think of it as a belated spring clean for your system. An enema for your constipated database.

Haven’t you read anything in this Topic ? ( Or couldn’t your LLM’s help you in this case :joy: )
ohhh, and Spook is Not an App, beside HACS has no Apps either

Thank you for the tip. It got my system stable from a far and from my phone.

This situation have made me think twice before hitting update!

My HA is on virtual box on a windows 10 machine and had 4 to 5 minutes reboots.

see above :wink:

Where did you get the idea that anything happened to my DB, or that i got affect by the “Deleted Devices” “issue” in the device.registry , Which this Topic is About ?
( Well maybe i actually did in this case( Topic) , but i have 30 deleted “devices” in my device.registry-file, some i can identify, some not ( Absolutely nothing i intend to do anything about)

Read “device.registry” , which btw is easy to edit in a txt-editor( You delete Entries, Not Entities ) If anything these Entries are “devices” ( If you know what is “grouped” into this “definition” in HA )( could be im lucky, because i started this Green in November, so nothing really piled up, or “bogus” integrations)
But as usual you Edit your Post’s to “adapt” to the facts you find in people responses, instead of “crossing over” your false statements and facts

I’m on 9.1 now and honestly ‘feels’ faster, snapper. Will do some timing later. But didn’t I read something in the relnotes where they actually clear out those deleteds for you? If so people don’t need to muck about in the device registry any more. Did I read that correctly?

ups, i just hit the update button, as i just read the “release note” update earlier, but first got the update minutes ago. But it’s should be an easy task to implement in a fix
( i actually have no idea why they save “deleted devices” entries )

Yes i does seems like it " Delete (deleted devices which have neither connections nor identifiers) " < from the github-fix

Edit: Nothing seems deleted in mine, thou they have identifiers,and most comes from HACS( and i know i have “tested” a few integrations, and removed them again) , 4 comes from hassio

I avoided 2026.9 because of reports of problems but the 2026.9.1 was fine for me on a PI5 with a USB data disk. Just a breadcrumb if you’re avoiding it because of issues previously reported.