Mats789
As people will probably chime-in to tell us about the problems they have related, or more probably unrelated, to this release It was a no-problem upgrade for me and running well. Good job 
As people will probably chime-in to tell us about the problems they have related, or more probably unrelated, to this release It was a no-problem upgrade for me and running well. Good job
Maybe it is a language thing. From this:
I understand that you want the developers to change your OS config.
The recent improvements to snapshots are included in the supervisor for all install types that utilise this container. It is up to you to configure your OS to utilise it as you have chosen a supervised install and manage your own OS.
apart from the argue above.
what does a user notice from this? is home assistant really faster, or is is just something you only notice while measuring.
And also does this also apply to RPI installations as those are based on RPI OS?
I just installes HA OS 11 and everything is running great, no issues so far.
1 reply
It features the same new look as the Home Assistant Core onboarding flow, and tracks issues during the bootstrapping phase, automatically displaying errors if they occur during that critical setup phase.
Always great to see that the HA developers keep making HA more newbie-proof and enjoyable, specially in the first phase of exploring HA.
Kudos for that 
I probably missed something, but most DB engines have a journal so that it can recover to the last committed (and consistent l state), for example after a crash. However, it’s also useful with ZFS and other FS with snapshotting feature, because any atomic snapshot can be recovered from. So an atomic snapshot is just as if the system crashed at that time, no notification needed.
So I guess that the notification here is needed if you don’t have atomic snapshots?
1 reply
I upgrade today while at work… no hiccups at all on my intel NUC. Happy days.
Generally, this is unlikely to lead to massive gains most of the time. In theory, this should mainly help when system usage (e.g. disk usage) is high, for example during backup.
There are synthetic scheduler tests which definitely prove that the configs lead to lower scheduling latencies. I’ve tried to measure the difference with some tests using Home Assistant Core’s automation engine. However, I wasn’t able to prove an improvement though: The changes seem too be too small on a idle system. I wrote some thoughts in the PR description of PR #2721.
On Raspberry Pi’s Linux kernel configuration, the PREEMPT scheduler has been used already before. So actually no change there.
Yes, this is typically guaranteed by databases which follow the ACID principles.
Right. I was under the assumption that QEMU/KVM snapshots are not atomic, but they actually might be, I am not sure. It might depend on the disk/VM configuration.
In any case, this change makes sure that during the snapshot time the database file remains in a consistent state in any case.
There is also some improvements on durability, at least when using SQLite: The way the recorder integration works today, some (recorder) tasks might be in flight. When locking the SQLite database, we issue another task (the lock task), and wait until that one is complete before completing the fs-freeze. So this essentially makes sure that all data in flight are saved too, before the snapshot is being taken.
Did these changes (mainly bluetooth improvements im guessing) have an impact on other radios as well? I’m noticing that my zha/skyconnect setup is performing noticeably better than before. Not sure if its the upgrade/reboot of my setup/coincidence tho.
The Bluetooth updates unfortunately broke some things as well. Specifically, the addon hassio-plejd, see Disconnects started happening after update to HAOS 11 · Issue #292 · icanos/hassio-plejd (github.com)
The addon uses a hassioaddons/base docker base image and talks to the Plejd BLE mesh using dbus-next - npm (npmjs.com) and bluetooth-hci-socket - npm (npmjs.com).
Any help in getting this to work (or info that this is a lost cause and will never work again) would be much appreciated!
Thanks
/Victor
Shutting down is certainly the safest option. It depends a bit how storage snapshot is implemented exactly in ESXi, if it is atomic it should also be safe at runtime.
In any case, I found that their guest utilities (open-vm-tools) support pre-freeze and post-thaw scripts as well. I’ll put it on our todo list.
One note for anyone else that might have both Zwave JS and ZWave JS UI add-ons installed but running Zwave JS as the Zwave engine: the HA 11 update restart somehow started the dormant Zwave JS UI add-on, which caused Zwave JS to stop working. It took me a while to figure out why. I uninstalled Zwave JS UI for now and all is well.
This update broke my installation, because the root partition has filled up. As a result it cannot write the new network configuration file for the end0 interface. Is there a solution for this?
Hi.
I Updated my virtualbox installation from 10.5 to 11. It started but it had a few problems (with sda8, and with supervisor etc). I followed the recommendations, and than rebooted the machine, and now it is not starting! There is just “Waiting for the Home Assistant CLI to be ready…”
What can I do now? I ma an backup with the ha before update, but not with the virtualbox. How can I fix this, or revert to 10.5?
Thanks
I found the problem and the fix here: Stuck waiting for home assistant cli to be ready · Issue #2272 · home-assistant/operating-system · GitHub