This just happened to me. It started with going through onboarding and HA startd reporting “ERR_EMPTY_RESPONSE” in the browser. When I went to cli, I saw the repeated error. I didn’t even get to log into HA.
I’ve also had this happen again since my original post, but have now been running OK for over a week.
Guys I see lots of posts with same error but without any updates. If someone has solved please let us know. If it’s still randomly happening and the only solution is to restore a previous backup, please let us know too…
I was having this issue with an RPi 4 and Argon One case with the NVME SSD version of the case.
It did somewhat resolve itself after a couple of reboots, but I was getting an undervoltage warning.
After I gave it a 20 watt power supply it hasn’t complained or have a SQUASHFS error again.
I’m wondering if is a side problem from a power issue.
having some problems that look to be related?
is there a way to fix this? rebuild the file system
or reboot make a backup and then reinstall is best way to go?
Getting the same issue today. RPi4 - Argon One case with the NVME SSD
Anyone else get this resolved?
It looks like this issue has struck me too - after running very reliably for some time, my HA is now complaining about SQUASHFS errors and failing to boot properly.
I’m running on a Pi4 with an SSD in an Argon One M.2 case and have tried switching power supply to rule that out.
This is massively frustrating as I’ve recently had a large solar panel setup and battery array installed and use HA to monitor that as well as a bunch of other home automation bits, so getting it back to a rliable state is a real priority!
New user here,
I downloaded the VM off the website yesterday and have run into this problem today.
My environment is as follows: HP Microserver running XigmanNAS with VirtualBox running. Storage is 4x Seagate Pipeline HD drives running as 1 ZFS pool with XigmaNAS running from a USB stick internally installed on the mainboard. No issues with the NAS as a whole, everything responsive and working as it has for several years.
I started up the VM yesterday and when it came up to the point of saying “this may take 20 mins” I went out to do some things. I came back last night and finished the first start wizard, and found my detected devices, in particular I have an ESPHome smart plug and an identical device but running Tasmota. I started through the process of setting up the Tasmota device by installing Mosquito and setting up a username etc. I decided to put off the final setup of the Tasmota device until today as I was tired. This morning, I got a “We’re having trouble finding this page” message on the browser. Ok, I’ll check the VM. Virtual box says running, the NAS is also fully responsive etc. VNC to the HA VM, and I see these errors as mentioned above.
Reading through some of the replies, I seem to be the first person reporting the fault with no SSD involved. OK, XigmaNAS is running from a USB stick, but the VM is on a spinning disk and shouldn’t knw about the USB stick I don’t think? This is my very first time with HA, and it’s broken less than 12 hours after configuring 1 and a half devices. I’m going to investigate further but does anyone yet have any ideas on a cause and or a fix?
Thankyou!
Hi there. First time posting here. Was anyone able to solve this error?
I started to have the same error almost every day or every couple of days. Home Assistant runs fine until it doesn’t.
I run a dedicated Pi 4gb ram with Hass OS on an SSD. Regular Sata drive.
I run HA for 2 months without doing anything to it after the initial set up. After I got everything integrated and mounted the wall tablet I started to have this issue.
Pi is connected to a 20w power supply and the enclosure for the Ssd is USB 3. The only other thing I have connected to it is Skyconnet using the supplied extension.
I run another pi as a Plex server using the same Ssd with 4 drives connected to it and never got any issues and it’s rock solid which makes me believe it’s not the Ssd.
Can anyone help? I would really like to have this sorted. Running latest HA 2024.2
I don’t know, but I did come across the following:
Hi, I ran into this problem as well - SQUASHFS/EXT4 errors and the system doesn’t start properly. This started a day ago, after updating to HA 2024.2. However, I am running an Intel NUC with a Samsung EVO M.2 SSD drive. I’ve never had any problems like this before - the last thing I did was update to 2024.2.1. I don’t think this problem has to do with RaspberryPI or USB in my case, it seems like something got corrupted?
I’m wondering what I can do to troubleshoot it. After book, I get the HA CLI, but its very unresponsive. Does HA have a “safe mode” or diagnostics tool?
After running for over 2 years I just got the same on Argon ONE M.2 SATA, Kingston 250GB SDD, but there were no major updates prior this occured, it just stopped working at night. It was running 2024.02. Yet it still boots up, but then crashes randomly after a few minutes. I tried updating to 2024.2.1 and all other possible HA updates, but did not help. After multiple crashes noticed it seem to last longer while connected to LAN rather than WiFi. Considently or not, several times it crashed when I was trying to log into HA.
Are there AddOns to chech if SSD is not corrupted?
Same problem for me today… RPi4 with Argon case. Updated to latest supervisor and 2024.2, and it dropped off the network. I hooked up KVM, and saw same SQUASHFS errors and data read errors… Two reboots didn’t resolve. I finally unplugged it, disconnected everything, and put it back together, and it all came back online… 
Chiming in, just got this this morning. I run an RPi4 with POE, so used the switch to reboot it a few times. Didn’t do it. Trying to rescue a backup now. (I know, I know!)
Has been running solid since 2020.
Hi,
Same problem here 
.
Using a RPI4 with Argon ONE M.2 case, HA has crashed suddenly and cannot be longer connected to my network.
SQUASHFS error to on boot.
Same issue… So no fixes huh?
I was having these errors with HA crashing intermittently last year on my Pi 4 running a USB SATA SSD and HAOS 10.5. Eventually HA would no longer boot. The crashing and errors disappeared after I replaced my SSD (and case) and restored my Home Assistant from backup. I did this 6 months ago and it has been stable since then.
The errors were similar to the OP:
EXT4-fs error (device sda8): __ext4_find_entry:1662: inode #131554: comm coredns: reading directory Iblock 0
and
[78702.586270] SQUASHFS error: Unable to read metadata cache entry [8383595]
[78702.588158] SQUASHFS error: Unable to read directory block [8383595:9f8]
The case was replaced with the same model, UGreen external M2 SATA case, so that was unlikely the fix. My hypothesis is that it was most likely corruption on the SSD (although I give some other possibilities below). I’m unsure if it was software or hardware corruption. It’s possible that a Linux equivalent of checkdisk, or a reformat and restore may have resolved it, rather than SSD replacement; but I had a spare SSD and the nuclear option worked for me.
Some other possibilities that could have resolved my issue:
- USB SSD adapter UAS mode blacklist — This comment on the HAOS repository references the blacklist which only gets updated on fresh HAOS installs. It’s possible that my SSD adapter needed UAS mode blacklisted, and this only applied on my reinstall. [Re-reading this thread I think there are other mentions of this too]
- HAOS version — The above Github thread also mentioned HAOS 10.x being problematic. When I first configured my new SSD, I installed the same version HAOS 10.5, then restored my backup. I then downgraded to HAOS 9.5 and ran it for a month (without issue), before upgrading to HAOS 11 (again without issue) and I’m now on 12.X.
- Custom integration iCloud3 — I first experienced the crashing shortly after updating from iCloud3 v3, Prerelease 1.1 to Prerelease v1.3. At the time I disabled the integration and I haven’t re-enabled it since. Disabling the integration did not fix the issue, but maybe it had somehow caused some corruption that could not be recovered from, perhaps too many writes to disk. I have nothing to back this up, I couldn’t find anyone else mentioning any crashing issues with the integration. I think it is more likely a coincidence that crashes occurred after the installation.
- USB Bluetooth Adapter — At one stage when I was experiencing the crashes last year, one of the last messages in my logs before the crash was
bluetooth_auto_recovery.recover] Bluetooth adapter hci0 [ADDRESS] successfully turned back ON. I disconnected the adapter, and have not connected it again. Again, disconnecting the adapter did not resolved the issue, but maybe damage was already done? I think this is unlikely too.
So the TL;DR of my experience:
Replacing my SSD fixed the issue, but a reformat of the SSD and a fresh HAOS installation may have done the trick.
I experienced this issue also randomly, after years of consistency.
What worked for me was to swap out my existing USB3 SSD Enclosure with this one from Ugreen: USB3 Gen2 Type-C 2.5" SATA 6Gbps HDD Enclosure (not an affiliate link, just a link to their website).
I’m still using the same SSD without issues
1 Like