operating-system
operating-system copied to clipboard
home-assistant
System not start
Describe the issue you are experiencing
After update to last version, the system dont start anymore. black screen and not keyboard abailable. Only ping responses. rpi 5 8Gb
What operating system image do you use?
rpi5-64 (Raspberry Pi 5 64-bit OS)
What version of Home Assistant Operating System is installed?
14.0
Did the problem occur after upgrading the Operating System?
Yes
Hardware details
rpi5
Steps to reproduce the issue
1.automatic from ha web 2. 3. ...
Anything in the Supervisor logs that might be useful for us?
i cant access the system to view
Anything in the Host logs that might be useful for us?
The sistem not start. I cant view anything
System information
No response
Additional information
No response
I also got this, upgrading to 14.2 from 14.1 on x86. I managed to boot back into 14.1 using this procedure:
https://github.com/home-assistant/operating-system/issues/2272#issuecomment-1600300443
The /dev/sda8 partition was named haaos-data-dis
Doing HAOS 14.2 Update from 14.1 I also got an unresponsive system. rpi5-64 as well.
Update: 11 minutes later, Unplugged power, and attached a USB mouse, USB keyboard, and HDMI monitor. When plugged back in power to troubleshoot, the system booted into HAOS 14.1 -- and Settings update was offering 14.2 Update again.
FWIW, rpi5 4GB HAOS on m.2 NVMe SSD
HAOS seems to know it was "bad"
Update: When plugged back in power to troubleshoot, the system booted into HAOS 14.1 -- and Settings update was offering 14.2 Update again.
FWIW, rpi5 4GB HAOS on m.2 NVMe SSD
ha > os info
board: rpi5-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "14.1"
B:
state: inactive
status: bad
version: "14.2"
data_disk: INTEL-SSDPEKNUO10TZ-PHKA12630BBY1P0B
update_available: true
version: "14.1"
version_latest: "14.2"
i get this afther update en try to restart in any way normal of save
Failed to perform the action homeassistant/restart. The system cannot restart because the configuration is not valid: Error loading /config/configuration.yaml: while scanning for the next token found character '%' that cannot start any token in "/config/sensors.yaml", line 8, column 12
i did not chnage any thing there just a update, is lucky my test server main server will not be updated so far
I am also getting this issue, RPi5 (I have tried to apply the change twice failed both times)
Three times in a row we pressed update, and all three times, after rebooting, the old version remained. After the fourth attempt to update, HA rebooted and the new version 14.2 was installed
I have a home assistant green and am no longer able to get it to boot after the 14.2 OS update. I don't have a HDMI monitor available to check the issue how can I get this to work again?
Update: After 4 reboots of the system I have access again and system returned back to OS14.1
Same here, after 3 failed tries to update, I gave up, still on 14.1 , HA OS installed on an RPi5.
Pareil ici, après 3 essais ratés de mise à jour, j'ai abandonné, toujours sur 14.1 (14.1), HA OS installé sur un RPi5.
Pushed the button on 14.2, failed to come up. I'm remote so could not see anything on a screen. IP was not offered from DHCP from the router so not pingable. Made me consider a cloud connected switch to reboot this. Asked somone at home to pull power and it came back up -my octopus rates card, restored and all back to 14.1.
Three times in a row we pressed update, and all three times, after rebooting, the old version remained. After the fourth attempt to update, HA rebooted and the new version 14.2 was installed
Same for me. RPI5
I also rebooted Hard cut power off en on, came in a recovery mode every thing was back core update and os update, but had problems with the setting sensors.yaml i trun it of and reboot system was ok one version lower updates are there and i don't touch them, now fix my sensors.yaml who i did not touch when i was updaten pretty strange.
For the people experiencing the Raspberry Pi not booting, after a system reboot (have to do a hard power-off and power-on to recover). It is likely #3740.
Seems like there's many ppl having issues with the upgrade to 14.2 - also me too. I would like to see a new build or version that is possible to upgrade without any issues. I'm stay on 14.1 After a faulty attempt to do 14.2.
I'm running HA on VirtualBox on Windows 11.
Upgraded to 14.2 today and it started crashing every few minutes. Update process was also very troubled, machine didn't come online several times and I couldn't reach it for more than 20 minutes.
Won't recommend updating to 14.2
In case if you need to roll back to 14.1:
ha os update --version "14.1"
@sairon FYI I know you are busy, but thought I'd bump this to the top of your notifications because this looks like a breaking regression, and seems different than past issues because it is happening on Home Assistant Green and VMs (not just RPI). I haven't experienced this yet because I haven't done the update yet, but would it be worth rolling back the release until the root cause is determined?
please fix hoe assistat
I think that is another service buddy :)
typo my bad
@sairon FYI I know you are busy, but thought I'd bump this to the top of your notifications because this looks like a breaking regression, and seems different than past issues because it is happening on Home Assistant Green and VMs (not just RPI). I haven't experienced this yet because I haven't done the update yet, but would it be worth rolling back the release until the root cause is determined?
@villasenor While we can't rule out anything, I don't feel there is a strong indication about a breaking regression affecting more platforms. Of course, the kernel update could have introduced some issues for particular hypervisors or Green as well but many other systems are running fine and I am not able to reproduce anything similar on my end either (upgraded Green couple of times in the morning and now it's running for couple of hours straight). Basically, with ~1M installs, every update which results in a host reboot wakes up some gremlins that were waiting for their prime time - if there's a real issue, we need to figure out the pattern, and we need logs for that.
What I unfortunately can't deny is that there's an issue with Raspberry Pi 5, it's been reported in couple of threads already and some summary can be found in post by @linux4life798. However, that is likely an intermittent problem that couldn't have been introduced by 14.2, as there are simply no changes between 14.1 and 14.2 that could have caused it. So far the common pattern is that it happens on RPi 5 running from NVMe on unofficial NVMe HATs. But being intermittent, it affects different people than before. And also, I still need to be able to successfully reproduce it here, I don't have any of the problematic HATs (yet) but with the official M.2 HAT+ or when running from an SD card, there are no issues.
For everyone, spamming issues with "me too" reports doesn't help anyone. If you want to comment, at least provide more details about your setup, i.e. is it running from an SD card or an NVMe? What HATs and peripherals are connected to it? Can you connect an HDMI display and check what's there? The more information, the better.
How can I produce logs? My update failed on x86 and rolled itself back to 14.1.
@sairon FYI I know you are busy, but thought I'd bump this to the top of your notifications because this looks like a breaking regression, and seems different than past issues because it is happening on Home Assistant Green and VMs (not just RPI). I haven't experienced this yet because I haven't done the update yet, but would it be worth rolling back the release until the root cause is determined?
@villasenor While we can't rule out anything, I don't feel there is a strong indication about a breaking regression affecting more platforms. Of course, the kernel update could have introduced some issues for particular hypervisors or Green as well but many other systems are running fine and I am not able to reproduce anything similar on my end either (upgraded Green couple of times in the morning and now it's running for couple of hours straight). Basically, with ~1M installs, every update which results in a host reboot wakes up some gremlins that were waiting for their prime time - if there's a real issue, we need to figure out the pattern, and we need logs for that.
What I unfortunately can't deny is that there's an issue with Raspberry Pi 5, it's been reported in couple of threads already and some summary can be found in post by @linux4life798. However, that is likely an intermittent problem that couldn't have been introduced by 14.2, as there are simply no changes between 14.1 and 14.2 that could have caused it. So far the common pattern is that it happens on RPi 5 running from NVMe on unofficial NVMe HATs. But being intermittent, it affects different people than before. And also, I still need to be able to successfully reproduce it here, I don't have any of the problematic HATs (yet) but with the official M.2 HAT+ or when running from an SD card, there are no issues.
For everyone, spamming issues with "me too" reports doesn't help anyone. If you want to comment, at least provide more details about your setup, i.e. is it running from an SD card or an NVMe? What HATs and peripherals are connected to it? Can you connect an HDMI display and check what's there? The more information, the better.
I have the following connected to my RPi-5
SSD connected using a SATA to USB3 cable, the OS is installed on the SATA drive, the PI does not have a SD card inserted. 1 Zigbee Dongle (Conbee II) 1 Zigbee Dongle (SONOFF ZigBee 3.0 USB Dongle Plus)
Edit, i yoloed it and tried to install the update again. It finished in a couple of minutes with out problem. I have not changed anything to the PI nor homeassistent in the meanwhile. I guess for me this problem resolved it self. Everything seems to be working just fine, including my zigbee devices.
Now running on:
Core 2025.1.4 Supervisor 2024.12.3 Operating System 14.2 Frontend 20250109.2
For everyone, spamming issues with "me too" reports doesn't help anyone. If you want to comment, at least provide more details about your setup, i.e. is it running from an SD card or an NVMe? What HATs and peripherals are connected to it? Can you connect an HDMI display and check what's there? The more information, the better.
out of the box raspi5 with out of the box raspi power supply. could be adguard related tho? this happened like immediately after I setup adguard
Same issues as other are stating here on a Pi5. I tried 3 times to update from 14.1 to 14.2. After the update it reloads and takes a good 30 minutes or more to come back up at which time I get SSL handshake errors. I then hard power cycle the Pi and then it will come back up, and still on 14.1. No custom integrations, all basic things.
I use a base Pi, stock Pi 5 power supply, no hats on the Pi, using a regular micro sd card. Pi is 8gb, plenty of space, easily replicated the issue 3 times.
Core 2025.1.4 Supervisor 2024.12.3 Operating System 14.1 Frontend 20250109.2
2025-01-27 21:08:22.818 ERROR (MainThread) [aiohttp.server] Error handling request Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/client_proto.py", line 92, in connection_lost uncompleted = self._parser.feed_eof() ^^^^^^^^^^^^^^^^^^^^^^^ File "aiohttp/_http_parser.pyx", line 508, in aiohttp._http_parser.HttpParser.feed_eof aiohttp.http_exceptions.TransferEncodingError: 400, message: Not enough data for satisfy transfer length header. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 480, in _handle_request resp = await request_handler(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 569, in _handle return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data for satisfy transfer length header.'> 2025-01-27 21:08:22.821 ERROR (MainThread) [supervisor.api] Failed to get supervisor logs using advanced_logs API Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/client_proto.py", line 92, in connection_lost uncompleted = self._parser.feed_eof() aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data for satisfy transfer length header.'> s6-rc: info: service legacy-services: stopping 2025-01-27 21:08:23.236 INFO (MainThread) [supervisor.misc.scheduler] Shutting down scheduled tasks 2025-01-27 21:08:23.237 INFO (MainThread) [supervisor.docker.monitor] Stopped docker events monitor 2025-01-27 21:08:23.238 INFO (MainThread) [supervisor.api] Stopping API on 172.30.32.2 [02:08:23] INFO: Watchdog restart after closing 2025-01-27 21:08:23.247 INFO (MainThread) [supervisor.hardware.monitor] Stopped Supervisor hardware monitor 2025-01-27 21:08:23.250 INFO (MainThread) [supervisor.dbus.manager] Closed conection to system D-Bus. 2025-01-27 21:08:23.252 INFO (MainThread) [supervisor.core] Supervisor is down - 0 2025-01-27 21:08:23.253 INFO (MainThread) [main] Closing Supervisor [02:08:23] WARNING: Halt Supervisor [02:08:23] INFO: Supervisor restart after closing
Same issue here on Raspi Pi5 8GB with Raspberry Pi SSD Kit with 512GB (Raspberry Pi M.2 HAT+ with Raspberry Pi NVMe SSD). No SD card connected. Nothing unofficial from my point of view. Coming from 14.1. Installed 14.2 and the machine didn't come back. Cut the power and waited for some minutes and the machine came back to 14.1 with the option to install 14.2 again.
Anyone with RPi 5 update failing, can you please post the output of ha host logs -v -n100 -t rauc and ha host logs -v -b-1 -t hassio_supervisor obtained right after the update fails and boots back to the old version? The cause for some reboot failures was identified and fixed in #3842, I need to confirm if it's anyhow related, because this one I'm not able to reproduce.
For anyone with issues on other platforms than Raspberry Pi 5 - most likely we're talking about a different issue, let's track it separately and keep this one strictly for RPi 5.