Home Assistant OS 18.0 #4780
Replies: 29 comments 48 replies
-
|
I have a Home Assistant Yellow with a Raspberry Pi 5. Do I need to heed the warnings and do something to update the bootloader, or is that handled for me? |
Beta Was this translation helpful? Give feedback.
-
|
I'm in the same boat - this is a bit confusing. When I run |
Beta Was this translation helpful? Give feedback.
-
|
I'm hoping to get an official answer as I am also in the same boat, but it looks like under Yellow, they are trying to warn us if we need to do it when we update:
Update: I took the leap. It worked without any extra commands by updating it from the HA UI |
Beta Was this translation helpful? Give feedback.
-
|
The system still boots, it's just the display output which is affected. Since the Yellow has no display output this combination is not problematic or rather it does not matter. It is safe to upgrade to OS 18. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't see the msg about the Pi5/Yellow before upgrading to v18 and then running the firmware updater command. I was on 2025-01-something. Everything was fine, though. I don't have a display. |
Beta Was this translation helpful? Give feedback.
-
|
Pay attention that updating the firmware does reset the boot order, so if you had set your HAOS to boot directly to the NVME you might run into issues. Mine still had the installation SD Card so HAOS booted from the SD Card, but removing the sd card and rebooting the Rpi5 correctly switched to the nvme. See #4811 |
Beta Was this translation helpful? Give feedback.
-
|
I’m curious about the statement that raspberry pi firmware can only be updated when booting from an sd card. I’m using a usb ssd drive so it’s unclear what I should do to update… |
Beta Was this translation helpful? Give feedback.
-
|
I‘ve just updated my pi 5 (nvme ssd) without problems, Firmware was older than 2025-12. I updated the bootloader afterwards with I assume My rpi5 with haos 18 has no external display attached, so I ignored this warning: |
Beta Was this translation helpful? Give feedback.
-
|
How a Yellow booting CM4 on SSD could be updated to latest f/w ? ~ # ha os boards raspberrypi firmware I tried to move my data partition back to CM4 MMC (32GB), but this failed with following error: |
Beta Was this translation helpful? Give feedback.
-
|
Hardware: Just tried upgrading HA OS from 17.3 to 18.0 just now. Hard reset by switching power off. Would um...wait a little bit more before trying it again, just finished prolonging Tuya dev Trial and re-linking my Local Tuya devices, enough tinkering for today. |
Beta Was this translation helpful? Give feedback.
-
|
The firmware update is only for the display output. The Yellow doesn’t have a display output. Does your CM4 even have an EEPROM? Mine doesn’t. |
Beta Was this translation helpful? Give feedback.
-
|
Running without an SD card. The update documentation suggest that the firmware update will only work if you’re running raspberry pie off an SD card. Many of us built our HAOS RPI systems by migrating the operating system to an SSD. Thoughts on how one might upgrade with this configuration? |
Beta Was this translation helpful? Give feedback.
-
|
What sort of hardware do you use? |
Beta Was this translation helpful? Give feedback.
-
|
I think they meant that you can only upgrade the bootloader firmware off an SD card, not Home Assistant OS. And regarding the firmware, I think this related to what was announced in 17.2 (see the How to update the bootloader section in this issue: #4627) |
Beta Was this translation helpful? Give feedback.
-
|
Apparently the outcome is that you lose a display. I don’t know how you get it back.Are you saying that you worked way through it and it came out the other side OK.? still have SSH I would imagineOn Jun 20, 2026, at 9:28 AM, Cody Cook ***@***.***> wrote:
I didn't see the msg about the Pi5/Yellow before upgrading to v18 and then running the firmware updater command. I was on 2025-01-something. Everything was fine, though. I don't have a display.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Question based on this comment on the readme "All users are recommended to update." I dont see any actual 'reasons' provided to justify. Of course, if a bug affecting the user is fixed, that itself is a reason but otherwise I'm not seeing any call-out for performance improvements, critical security fixes, etc It would be nice to have those with specific knowledge, be posting some sort of summary with each release, like this hypothetical |
Beta Was this translation helpful? Give feedback.
-
|
We don't continue to update the previous major release (17.x). So yeah this is mostly about bug and security fixes on OS level you won't receive anymore. The CVE list would be massive. And the upstream kernel doesn't even provide a list of addressed CVE's. Unfortunately we don't have the resources to really track CVEs individually just to provide a list of what all got addressed. The Buildroot bump has a list of CVE's of all CVEs if you are interested in (note that HAOS doesn't use all the packages, the PR comment has a list of packages we are using which got updated): |
Beta Was this translation helpful? Give feedback.
-
|
Worried about updating my Home Assistant Blue (Odroid N+) after reading the issue people are having with their devices not booting or being corrupted. Is it safe to update now or will there be other fixes coming to address the reported issues? How common is it? |
Beta Was this translation helpful? Give feedback.
-
|
What issues? |
Beta Was this translation helpful? Give feedback.
-
Ethernet link flapping on Raspberry Pi 5 after upgrading to HAOS 18.0 (kernel 6.18)After upgrading from HAOS 17.3 to 18.0, my Raspberry Pi 5 started experiencing continuous ethernet link flapping every ~6-10 seconds. The dmesg output showed a repeating This cycled continuously, causing:
Troubleshooting steps taken (none resolved the issue):
Resolution: Rolling back to HAOS 17.3 via ha os update --version 17.3 immediately resolved the issue. After reboot, dmesg shows a single Link is Up at boot with no further This points to a regression in the macb ethernet driver introduced with the kernel upgrade from 6.12 (HAOS 17.3) to 6.18 (HAOS 18.0). |
Beta Was this translation helpful? Give feedback.
-
I see that here, too, but not as often. Oh wait, that's a test-instance, Pi5 with OS 18.1.dev20260618. The other Pi5 with OS 18.0 doesn't show that. |
Beta Was this translation helpful? Give feedback.
-
|
Home Assistant Green with Connect ZBT-2 successfully updated from 17.3 to 18.0. Everything running OK. |
Beta Was this translation helpful? Give feedback.
-
|
Esprimo Q920 Generic x86-64 with Sonoff Dongle Max successfully updated to 18.0. Everything working fine! |
Beta Was this translation helpful? Give feedback.
-
|
Proxmox vm not a problem |
Beta Was this translation helpful? Give feedback.
-
|
Upgrade from 17.3 to 18.0 (ova VM running on TruNAS) effectively bricked my HA system, but I have been able to revert/recover to 17.3by flipping boot partition via console access and rebooting (nice feature!). I’ve not had chance to do any troubleshooting yet, but symptoms suggest a nice/network issue |
Beta Was this translation helpful? Give feedback.
-
|
Hey, Helipaddy -Where did you find the doco for this revert?SteveC-GINVOn Jun 21, 2026, at 2:11 PM, Jason-Pugh ***@***.***> wrote:
Upgrade from 17.3 to 18.0 (ova VM running on TruNAS) effectively bricked my HA system, but I have been able to recover by flipping boot partition via console access and rebooting (nice feature!). I’ve not had chance to do any troubleshooting yet, but symptoms suggest a nice/network issue
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Just use |
Beta Was this translation helpful? Give feedback.
-
|
On CM5 running 2025.11.x firmware, was able to upgrade to latest without any problem. But SD card thing is big confusing here. |
Beta Was this translation helpful? Give feedback.
-
What do you mean? |
Beta Was this translation helpful? Give feedback.
-
|
A few ideas on howto: If you leave your RPI5 in preffering to boot via SD and second choise set as SSD. You can rather easy create a SD card image that the RPI will boot from if SD is 1's choice. I called my new raspbian host "FIXUP" and let my normally SSD booting HA boot from the SD card instead. Connect when its booted with "ssh [email protected]" and there do your eeprom check ( i.e. which version u have and if there is a fresh one from 2026 ) Do the update. shutdown, power off by pulling the USB-C cable.. take out the SD card, power up and it should be fine. |
Beta Was this translation helpful? Give feedback.
-
|
Actually this would be the way to install HAOS on a SSD also.. Start your RPI with GUI on the SD card.. Look for the RPI imager firmware.. Flash the latest HAOS , let it wait until everything is done.. then poweroff, Unplug power , remove SD card.. Powerup again.. WIth a screen you will see a little what happens.. This as a hint if you need to restore now if you have run into issues and need to revert.. |
Beta Was this translation helpful? Give feedback.
-
|
After upgrading from 17.3 to 18.0 my Open Thread Border Router addon keeps crashing so I cannot use my ZBT-2. I run HAOS through Proxmox and have had a fully working ZBT-2 connection before. |
Beta Was this translation helpful? Give feedback.
-
|
Is maybe another App accessing the same serial port? If apps are using |
Beta Was this translation helpful? Give feedback.
-
|
In Proxmox I passed both USB port and the device by-id which apparently caused this issue (eventhough it has worked before, but I think I didn't reboot the device in all the time since I got the ZBT-2). Removing one of these entries resolved it. |
Beta Was this translation helpful? Give feedback.
-
|
Almost the same issue for me.. Except my usb stick had a older firmware causing the probes to fail.. Flashed with a fresh as possible firmware and it looked a little better but in the end i had to uninstall OBTR and reinstall it again.. My test Kajplats bulb worked but my my Bilresa failed.. Took anodther few hours to get that to work again.. I got to 90% of rejoin and then an error..:-) |
Beta Was this translation helpful? Give feedback.
-
|
And Bilresa.. I forgot to rember that a friend told me to use only rechargable.. 1.2Volts. Normal AAA 1.5Volts tends to fail.. So even if i slightly got in contact with my BILRESA.. It in the end failed..:-) |
Beta Was this translation helpful? Give feedback.
-
|
I only have 2 matter devices from Ikea.. Yup.. Dead.. One router / lamp bulb , one bilresa.. None alive.. But as these are only for a test its not a big issue for me.. Looks more like a very restrictive ( or bad IP ) access to the matter server.. |
Beta Was this translation helpful? Give feedback.
-
|
Anyone able to help with running that rpi-eeprom-update command for Raspberry Pi 5? I connected a display and keyboard, assuming I could run that in the ha command line, but it's an unrecognised command according to the terminal? |
Beta Was this translation helpful? Give feedback.
-
|
Will go down that route if there's no way to satisfy the prerequisites before updating thanks. I must be doing something wrong though given this is the "recommended" upgrade path? |
Beta Was this translation helpful? Give feedback.
-
|
The command is listed under ‘Noteworthy changes’, which means it will only be available after the update. |
Beta Was this translation helpful? Give feedback.
-
|
The command is listed under a prerequisite to be run before the update so that's not correct (if you're responding to me). But it looks like GitHub has updated steps different to the release announcement: "To update the bootloader before installing Home Assistant OS 18, use one of the following methods: Use login to get to the OS prompt, then run rpi-eeprom-update -a while connected directly to the device (using a display and keyboard), prior to installing the OS update." I guess I'm missing that login step, will report back |
Beta Was this translation helpful? Give feedback.
-
|
Ah sorry. I meant this one: |
Beta Was this translation helpful? Give feedback.
-
|
Confirmed, I was just missing the "login" instruction which was in this updated page 👍 if anyone has the same question |
Beta Was this translation helpful? Give feedback.
-
|
Got it. Had you initially migrated HAOS to the SSD, or were you still running HAOS off the SD, and data on the SSDI am running everything off the SSD with the SD slot unoccupied On Jun 22, 2026, at 9:32 AM, viprex82 ***@***.***> wrote:
I updated to haos 18 first and updated the bootloader firmware afterwards via SSH App (Advanced SSH and Web Terminal) and
ha os boards raspberrypi firmware update
without problems.
running rpi5 with nvme ssd.
Please be aware that you won‘t be able to get display output before updating the bootloader to a current version. I ignored that because I never use a display, only the ssh terminal in HA.
Please also keep in mind that the firmware update will only work after upgrading to haos 18y
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Running from ssd for a long time now, sdcard slot is empty. |
Beta Was this translation helpful? Give feedback.
-
|
No big issue to have the RPI5 to boot from the SD card instead of the SSD unless you have set the RPI to prefer SSD instead of SD.. If you boot from SD card as 1st choice.. Just create a slim latest raspbian.. Name it like fixup and then ssh to it like "ssh @fixup.local" and do the eeprom update.. Just takes a few minute or 2 and you are all good. For me this felt like the safe way..:-) |
Beta Was this translation helpful? Give feedback.
-
|
Home Assistant Green loses Ethernet (NO-CARRIER) after upgrading to HAOS 18.0 Hardware
Working version
Broken version
Problem After updating from HAOS 17.3 to 18.0 via the Home Assistant UI, the Ethernet interface stops working completely. Symptoms:
__stmmac_open: HW setup failed
low voltage detected (This warning disappears after booting back into 17.3, so it may be unrelated or another regression.) Recovery I switched back to the previous OS slot: ha os boot-slot B The system booted into HAOS 17.3 and Ethernet immediately started working again without changing:
This appears to be a regression introduced in HAOS 18.0 on Home Assistant Green. |
Beta Was this translation helpful? Give feedback.
-
|
Since updating to Home Assistant OS 18 and Core 2026.6.4, my MariaDB app (add-on) keeps getting terminated by the system: I have therefore reverted to OS 17.3, and everything has been running stably ever since (with Core 2026.6.4). The hardware is a Yellow with CM4 (2 GB RAM). I couldn’t see any spikes or similar issues in the memory usage or similar metrics that might explain this behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the note for Pi4
Can someone explain this please? Does this need to be done? What exactly needs to be done? What happens if I don't? Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I assume this means switching device overlays. See Also:
New Overlay dtoverlay=vc4-kms-v3dOld Overlay Delete or comment out the line with vc4-fkms-v3d dtoverlay=vc4-fkms-v3dThis is my pi4 section. I use a Raspberry Pi 4. Put the configs in a different section if you have different hardware. [pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
# I use cma-256 to give the GPU more memory. The default is 64MB according to Mesa3D VC4 docs.
# I use HAOS Kiosk Display to show the dashboard on the console. Bumping CMA to 256MB gives the GPU more to play with.
dtoverlay=vc4-kms-v3d,cma-256
#dtoverlay=vc4-fkms-v3d
max_framebuffers=2
# Enable boost from 1.5Ghz to 1.8Ghz on compatible models
arm_boost=1You will also see CMA reservations very early in the kernel logs. Use |
Beta Was this translation helpful? Give feedback.
-
|
I find this also confusing. What if I don't do something in my config.txt? Will it just continue to use the old driver and that is fine, or would I run into problems? |
Beta Was this translation helpful? Give feedback.
-
|
Yea, I'm still a bit baffled by it. The note in the release notes really should be more descriptive. My understanding is that as infomaniac50 said, the line in config.txt needs to be changed from However I do not know the consequences of NOT doing this. My semi-educated guess is that the video output from the Pi's HDMI port may not work? If you're running headless like me it may not matter (unless you try to plug a display into the Pi for some purpose). I'm also having trouble getting to config.txt. From my Googling about it, I'm definitely not alone. I haven't done the update to HAOS18 yet. Waiting to work out what this is all about and if I need to fix it before the update. 🤷♀️ |
Beta Was this translation helpful? Give feedback.
-
|
TLDR: The old vc4-fkms-v3d driver is still available on HAOS 18. It won't hurt anything if you don't swap beforehand. HAOS 18 seems to be based on Debian Bullseye where the old drivers are still available but deprecated. Both drivers do the same thing but the FKMS driver is basically a shim to the VideoCore firmware blob. With the new driver the blob is removed and all hardware functions are controlled directly by Linux. In Debian Bookworm the old FKMS driver is fully removed. I'm not sure what the bootloader does about overlays that don't exist. Eventually the old FKMS driver will be removed from HAOS too and you won't have a display output. However that won't matter if you're running a headless server. In order to edit /boot/config.txt you have to remove the SD card and edit the file on a PC. Or you can to enable direct host access through SSH. https://developers.home-assistant.io/docs/operating-system/debugging/ The Advanced SSH & Web Terminal won't work because it runs inside a Docker container. Even with protection mode off there are no mounts that let you access the underlying filesystem. If your device boots from eMMC then you must use the SSH method. You can use a USB SSD enclosure for NVMe and SATA drives. Otherwise you'll have to use the SSH method. The following is what I got from the AI chatbot at https://www.raspberrypi.com/documentation/computers/legacy_config_txt.html (Prompt: fkms). The AI is not consistent with it's output so you might get something different. FKMS (Fake Kernel Mode Setting)FKMS ( How it worksWhile the firmware still controls the low-level hardware (e.g. HDMI ports, DSI, DPI), standard Linux libraries are used in the kernel itself. It essentially provides a KMS API as a shim over the underlying firmware-based graphics drivers, rather than controlling the hardware directly. [Buster to Bullseye] Current status
Reverting to FKMS on Bullseye (temporary workaround)If you need to fall back to FKMS on Bullseye, edit to:
RecommendationMigrate to the full KMS driver ( |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the more detailed description. I have managed to get SSH access to the host system. I do see that there's a new note Should those of us who haven't updated yet hold off until 18.1 is released? |
Beta Was this translation helpful? Give feedback.
-
|
Note for update bootloader after OS18 installation: The recommended bootloader firmware update procedure, with Advanced SSH described in this release, not works in original Raspberry Pi 4B board, seems that only works with yellow and green boards:
Returns: I found alternative metod to update de bootloader EEPROM, with Advanced SSH terminal, after (or before) OS18 installation: To check the current bootloader firmware: To update the bootloader firmware:
I think that this metod can also update bootloader before upgrade the Home Assistant to OS 18, and prevent problems involved with this update. |
Beta Was this translation helpful? Give feedback.
-
|
Somehow I missed this description too :-( I am getting the current version of the boot loader: However it does not let me update, since I am booting HAOS from USB/SSD: Therefore I will try prepare a new SD card with the bootloader image and see, if booting fom this will update the bootloader, as suggested here ... |
Beta Was this translation helpful? Give feedback.
-
|
Thé 18.0 update is not proposed anymore to my RPi 5 |
Beta Was this translation helpful? Give feedback.
-
|
Same here |
Beta Was this translation helpful? Give feedback.
-
As mentioned above: The Home Assistant OS 18.0 release has been removed from the stable channel (since OS updates are not working on old firmware and due to #4811). For users who already updated to HAOS 18.0, make sure to upgrade the Raspberry Pi 5 firmware using ha os boards raspberrypi firmware update before running the next Home Assistant OS update. |
Beta Was this translation helpful? Give feedback.
-
|
Do you have a red book for migrating to full KMS?On Jun 28, 2026, at 11:13 AM, Derek Chafin ***@***.***> wrote:
TLDR: The vc4-fkms-v3d driver is still available for now but might go away in the future. If you care about display output then swap vc4-fkms-v3d with vc4-kms-v3d on a PC or through the direct SSH method.
HAOS 18 seems to be based on Debian Bullseye where the old drivers are still available but deprecated. The FKMS driver is basically a shim to the VideoCore firmware blob. With the new driver the blob is removed and all hardware functions are controlled directly by Linux. In Debian Bookworm the old FKMS driver is fully removed. I'm not sure what the bootloader does about overlays that don't exist. Eventually the old FKMS driver will be removed from HAOS too and you won't have a display output. However that won't matter if you're running a headless server.
In order to edit /boot/config.txt you have to remove the SD card and edit the file on a PC. Or you can to enable direct host access through SSH. https://developers.home-assistant.io/docs/operating-system/debugging/ The Advanced SSH & Web Terminal won't work because it runs inside a Docker container. Even with protection mode off there are no mounts that let you access the underlying filesystem. If your device boots from eMMC then you must use the SSH method. You can use a USB SSD enclosure for NVMe and SATA drives. Otherwise you'll have to use the SSH method.
The following is what I got from the AI chatbot at https://www.raspberrypi.com/documentation/computers/legacy_config_txt.html (Prompt: fkms). The AI is not consistent with it's output so you might get something different.
FKMS (Fake Kernel Mode Setting)
FKMS (vc4-fkms-v3d) is a graphics driver for Raspberry Pi that sits between the legacy graphics stack and the full KMS driver.
How it works
While the firmware still controls the low-level hardware (e.g. HDMI ports, DSI, DPI), standard Linux libraries are used in the kernel itself. It essentially provides a KMS API as a shim over the underlying firmware-based graphics drivers, rather than controlling the hardware directly. [Buster to Bullseye]
Current status
Buster: FKMS was the default graphics driver.
Bullseye: FKMS is deprecated in favour of the full KMS driver (vc4-kms-v3d). It can still be enabled as a temporary fallback.
Bookworm: FKMS is no longer supported. Only KMS is available. [Bullseye to Bookworm]
Reverting to FKMS on Bullseye (temporary workaround)
If you need to fall back to FKMS on Bullseye, edit /boot/config.txt and change:
dtoverlay=vc4-kms-v3d
to:
dtoverlay=vc4-fkms-v3d
Note: This is not recommended as FKMS is unsupported, and there is no guarantee it will remain available in future Raspberry Pi OS releases. [Buster to Bullseye]
Recommendation
Migrate to the full KMS driver (vc4-kms-v3d) as soon as possible, as it provides direct hardware control, no closed-source firmware blobs, HDMI hotplug support, and multi-display integration. [KMS HDMI Troubleshooting]
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Changing Display Drivers to Full KMS on Raspberry Pi.Prerequisites
Getting Access to the HostHAOS is designed to be an immutable operating system. Most things are read-only so there isn't much use in having access to the underlying filesystems. Except in the case you have to make changes to config.txt in the boot partition. Normally this is done by shutting down Home Assistant and removing SD card to edit config.txt on a PC. These instructions will let you access the host on an separate SSH port unlike the unprivileged Docker container that runs the SSH Terminal app. Formatting the USB DriveFind a spare USB drive and format it with FAT32, ext4, or NTFS. You MUST name the drive volume 
Creating the authorized_keys FileCreate a file named 
Import the ConfigurationPlug the USB into the Home Assistant server, then reboot it or run Connect to the Host SSHConnect to the SSH server on the separate port. From the terminal 
Edit config.txtVerify the boot partition is mounted and is not read-only.
Go to the boot directory and verify config.txt exists. Verify both v3d drivers exist in the overlays directory. The only editor available on HAOS is vi. Edit the config.txt file with 
Note that in my config.txt file the changes were done in the After you make your edits hit Reboot HAOS |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
HAOS 18 will not start in a VM. HAOS 17.3 runs on that VM. HAOS 18 runs on Windows 11 Hyper-V |
Beta Was this translation helpful? Give feedback.
-
|
Is there any chance to modify the boot configuration of HAOS 18 to ignore event 1? |
Beta Was this translation helpful? Give feedback.
-
|
I am running HAOS 18.1 on a Rasberry Pi 4B, booting from an SSD, that is connected via USB.
I think, the release notes does not clearly describe, how to update the firmware, if HAOS is booted from SSD. My current state is this:
According to this output, my firmware is 3 years old, and should be updated I believe. I guess I can update the firmware by booting HAOS 18.1 from a freshly flashed SD card? Thanks for any clarification! |
Beta Was this translation helpful? Give feedback.
-
|
You're right, it's not user friendly. Nor is it well described in the note in the release notes. Mounting your SSD in your laptop is definitely one option. Edit: Discussion: #4780 (reply in thread) Step-by-step instructions: #4780 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
Tried this just now, unfortunately didn't worked for me.
Maybe I did something wrong, but to me it looks like CM4 with eMMC cannot as easily be flashed from MicroSD. Or after official procedure is posted. |
Beta Was this translation helpful? Give feedback.
-
|
I posted 2 weeks ago a procedure to update the firmware without SD: https://github.com/home-assistant/operating-system/discussions/4780#discussioncomment-17456260 |
Beta Was this translation helpful? Give feedback.
-
Oh, I was trying to watch this thread but probably missed it anyway. |
Beta Was this translation helpful? Give feedback.
-
I don't know why if clicks the link doesn't works. But if you copy the link and paste in a new window works... It's in the same discussion above |
Beta Was this translation helpful? Give feedback.
-
|
Well this explains a lot, I picked the wrong time to try and do a fresh install on a new SSD. Thought it might have been an issue with the hardware or my network during core install. Turns out it was home assistant / my old boot loader version all along. It's a bit of a rough breaking change tbh but I guess that's why it's a major release and not a minor. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Home Assistant OS 18.0 is a major release bringing significant updates to all platforms. The Linux kernel has been updated from 6.12 to 6.18 across all targets, Docker has been upgraded to v29.5.3 with containerd v2.2.4, and the underlying Buildroot has been updated to 2025.02.14. Disk images are now significantly faster to flash, the default swap size is now bounded to avoid problems on systems with very low or very high amounts of RAM, and the Raspberry Pi bootloader firmware can now be updated directly from Home Assistant. All users are recommended to update.
Noteworthy changes
Raspberry Pi firmware updates
The Raspberry Pi bootloader (EEPROM) firmware can now be checked and updated directly from Home Assistant OS. Use the following CLI commands to show the current firmware status and to install an update:
Home Assistant Core 2026.7.0 will also expose the firmware as an update entity. Note that updating the firmware is only possible when the system is booted from an SD card, or in general on Raspberry Pi 5 and on Home Assistant Yellow with a CM5.
Note that Rasbperry Pi 5 now requires firmware 2025-02-12 or newer. See the Raspberry Pi section below for details.
Default swap size
The default swap file size was previously set to 33% of the system RAM, which produced a swap file too small to be useful on low-RAM systems and an unnecessarily large one on systems with plenty of RAM. The default size is now clamped between 1 and 4 GB:
Leaner disk images and faster flashing
Disk images no longer overprovision the data partition, it is now sized to fit only its initial contents. Since the published images are compressed, the download size is not affected, but flashing is considerably faster, because the unused space at the end of the filesystem no longer needs to be written to the target storage. As before, the data partition is automatically expanded to use the available space on first boot.
Images for virtual machines (Open Virtual Appliance and the aarch64 VM formats) are pre-sized to 32 GB, so they no longer need to be resized before use.
Unified "haos" naming
The mix of legacy
hassos/HassOSand newerhaosnaming across the operating system has been harmonized tohaos. Most visibly, systemd units and helper binaries previously prefixedhassos-are now prefixedhaos-. If you have scripts or tooling that reference these names on the host (for example via the console or host logs), they may need adjusting. On-disk partition and filesystem labels are unchanged, so existing installations are not affected by the rename.Smoother first boot and landing page
The landing page, shown during the initial setup before Home Assistant Core has finished installing, has received a number of improvements that make the first boot easier to follow.
Downloading and installing Core on a fresh system can take a while, especially on slower connections, and until now the landing page gave no indication of how far along the process was. It now shows a progress bar while Core is being downloaded, so it is clear that something is happening and roughly how much is left.
The initial mDNS announcements during the first boot have also been fixed. The device now announces itself correctly from the start, so it can be discovered in the mobile apps right away while the system is still setting itself up, without having to wait for the Core installation to complete.
Home Assistant Operating System
_workstation._tcpservice annoucement from HAOS (Drop_workstation._tcpservice annoucement from HAOS #4739) @agnersRaspberry Pi
Note
The Home Assistant OS 18.0 release has been removed from the stable channel (since OS updates are not working on old firmware and due to #4811). For users who already updated to HAOS 18.0, make sure to upgrade the Raspberry Pi 5 firmware using
ha os boards raspberrypi firmware updatebefore running the next Home Assistant OS update.Important
Raspberry Pi 5 users need a bootloader from at least 2025-02-12, otherwise the display output may stop working early during the boot. You can update after installing the Home Assistant OS 18 update but you won't have display output in case the update fails. So if you decide to update first, make a backup and download it just in case.
ha os boards raspberrypi firmware updateover SSH to make the display output work again.To update the bootloader before installing Home Assistant OS 18, use one of the following methods:
loginto get to the OS prompt, then runrpi-eeprom-update -awhile connected directly to the device (using a display and keyboard), prior to installing the OS update.The Yellow with CM5 has no display output and is therefor not affected from this problem.
Note
The default graphics (DRM) driver on Raspberry Pi 4 has been switched from the legacy, no longer maintained FKMS driver to the modern KMS driver, which among other things enables HDMI-CEC support. This only applies to new installations. On existing ones,
config.txtin the boot partition must be adjusted manually to make the switch.Home Assistant Yellow
Note
The Home Assistant OS 18.0 release has been removed from the stable channel (since OS updates are not working on old firmware and due to #4811). For users who already updated to HAOS 18.0, make sure to upgrade the Yellow CM5 firmware using
ha os boards raspberrypi firmware updatebefore running the next Home Assistant OS update.Home Assistant Green
Open Virtual Appliance
Generic x86-64
Hardkernel ODROID
Khadas VIM Series
Generic aarch64
Build System
Documentation
Dependencies
Dependency updates (click to expand)
This discussion was created from the release Home Assistant OS 18.0.
Beta Was this translation helpful? Give feedback.
All reactions